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 [containers] Status: New Submitter: Jonathan Wakely Opened: 2024-11-21 Last modified: 2025-02-07
Priority: 4
View other active issues in [containers].
View all other issues in [containers].
View all issues with New status.
Discussion:
The Containers clause often uses "references, pointers, or iterators" which is verbose, and needs to be said in full whenever talking about iterator invalidation. It would be helpful to have a term of art that refers to all of them, something like "element references" or to avoid any confusion with actual references, "element indicators". Maybe "element handles" but that could be confused with node handles for associative containers, and (based on Wikipedia) has connotations of additional indirection, and something which would not be invalidated when the underlying storage changes.
[2025-02-07; Reflector poll]
Set priority to 4 after reflector poll.
"Maybe 'pointer to elements' or a longer phrase that includes the verb 'invalidates', which has special meaning in this section."
"Note that there are cases where we invalidate iterators but not pointers/references."
"Maybe define 'addresses' to mean 'pointers and references' since they're always invalidated at the same time, but iterators are sometimes separate."
"Referential element accessors"
"Define 'pointer-invalidating' (for both pointers and references) and 'iterator-invalidating', and say that the former always implies the latter. Maybe also introduce antonyms 'pointer-preserving' and 'iterator-preserving'."
"Should be defined in terms of affected elements, e.g. 'pointer-invalidating for any erased elements'."
Proposed resolution: