This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
Section: 23.2.7.1 [associative.reqmts.general] Status: New Submitter: Joaquín M López Muñoz Opened: 2021-08-04 Last modified: 2021-08-20
Priority: 3
View other active issues in [associative.reqmts.general].
View all other issues in [associative.reqmts.general].
View all issues with New status.
Discussion:
For the expression a.merge(a2), postconditions say that "iterators referring to the transferred elements
[…] now behave as iterators into a […]". When a and a2 are of different
types, this seems to imply, under the widest interpretation for "behaving as", that a-iterators and
a2-iterators are actually of the same type, that is, that associative containers have SCARY iterators,
which is, to the best of my knowledge, not currently mandated by the standard.
Indicate that "behaving as" only applies to the case where a and a2 are of the same type.
Clarify what "behaving as" means. A non-SCARY interpretation is that an a2-iterator to a transferred
element can still be dereferenced, incremented (if not past the last element of a) and decremented (if
not pointing to the first element of a), while comparison with a-iterators and use in the
interface of a is not guaranteed.
Mandate SCARY iterators by, for instance, requiring that associative containers with compatible nodes (23.2.5.1 [container.node.overview]/1) have the same iterator types.
Note that this issue does not extend to unordered associative containers, as there (23.2.8.1 [unord.req.general]) iterators to transferred elements are invalidated, which makes the point of SCARYness irrelevant. That said, if SCARY iterators are finally required for associative containers, it makes much sense to extend the requirement to unordered associative containers as well.
[2021-08-20; Reflector poll]
Set priority to 3 after reflector poll.
Proposed resolution: