Title
Iterator SCARYness in the context of associative container merging
Status
new
Section
[associative.reqmts.general]
Submitter
Joaquín M López Muñoz

Created on 2021-08-04.00:00:00 last changed 1 month ago

Messages

Date: 2021-08-15.00:00:00

[ 2021-08-20; Reflector poll ]

Set priority to 3 after reflector poll.

Date: 2021-08-08.11:37:50

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.

There are (at least) three possible resolutions to this ambiguity, ordered by intrusiveness:

  • 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 ([container.node.overview]/1) have the same iterator types.

Note that this issue does not extend to unordered associative containers, as there ([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.

History
Date User Action Args
2021-08-20 17:17:04adminsetmessages: + msg12007
2021-08-04 00:00:00admincreate