Skip to content

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

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

Description

@morinmorin
morinmorin
opened on Sep 26, 2019

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.)

Activity

  1. CaseyCarter commented on Sep 26, 2019

    @CaseyCarter
    CaseyCarter
    on Sep 26, 2019
    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].

  2. morinmorin commented on Sep 27, 2019

    @morinmorin
    morinmorin
    on Sep 27, 2019
    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)?

  3. morinmorin commented on Sep 28, 2019

    @morinmorin
    morinmorin
    on Sep 28, 2019
    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.

  4. morinmorin commented on Oct 11, 2019

    @morinmorin
    morinmorin
    on Oct 11, 2019
    Author

    This is now LWG 3301.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions