Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix transform_view::iterator::iterator_category when iter_reference_t is not an lvalue ref #637

Open
morinmorin opened this issue Sep 26, 2019 · 4 comments

Comments

@morinmorin
Copy link

Since iter_reference_t<transform_view::iterator> can be a type that is not an lvalue-reference, the current wording on its iterator_category needs to be fixed.

Proposed Resolution

Change [range.transform.iterator] p2 as follows:

+ \tcode{iterator::iterator_category} is defined as follows:
  — Let `C` denote the type `iterator_traits<iterator_t<Base>>::iterator_category`.
+ — If `is_lvalue_reference_v<iter_reference_t<iterator_t<Base>>>` is `true`,
    — If `C` models `derived_from<contiguous_iterator_tag>`, 
      then `iterator_category` denotes `random_access_iterator_tag`. 
    — Otherwise, `iterator_category` denotes `C`.
+ — Otherwise, `iterator_category` denotes `input_iterator_tag`.

Making iterator_category unconditionally input_iterator_tag would be the safest fix, but I think the above fix works fine.

(I'm planning to submit this to LWG in a few days.)

@CaseyCarter
Copy link
Collaborator

A model of input_iterator may fail to meet the Cpp17InputIterator requirements by being move-only, or by not being Cpp17EqualityComparable. That said, I think trying to list out properties case-by-case for each Cpp17 iterator category and each iterator adaptor that needs to decide its iterator category is a design error. We should use conccepts to decide whether an iterator meets the requirements of the various Cpp17 categories - ideally the exposition-only concepts from [iterator.traits].

@morinmorin
Copy link
Author

A model of input_iterator may fail to meet the Cpp17InputIterator requirements by being move-only, or by not being Cpp17EqualityComparable.

That's right, ouch...

We should use conccepts to decide whether an iterator meets the requirements of the various Cpp17 categories - ideally the exposition-only concepts from [iterator.traits]

Agreed. Is that equivalent to not defining nested iterator_category in the adapted iterator (and then users query the iterator category through std::iterator_traits<…>::iterator_category)?

@morinmorin
Copy link
Author

A model of input_iterator may fail to meet the Cpp17InputIterator requirements by being move-only, or by not being Cpp17EqualityComparable.

So, this means that the specification of iterator_category for many of range adaptor's iterators ([range.adaptors]) and iterator adaptors ([predef.iterators]) needs to be fixed.

@morinmorin
Copy link
Author

This is now LWG 3301.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants