Created on 2019-10-07.00:00:00, last changed 2019-10-07.21:12:50.
This wording is relative to N4830.
[Drafting note: 3247 touches the same wording in [iterator.cust.move]; if both are resolved simultaneously the changes should be reconciled before passing them on to the Editor.]
Modify [iterator.cust.move] as follows:
(1.1) — iter_move(E), if
that expression is valid,with overload resolution performed in a context that does not include a declaration of ranges::iter_move.
Modify [iterator.cust.swap] as follows:
(4.1) — (void)iter_swap(E1, E2), if
that expression is valid,with overload resolution performed in a context that includes the declarationand does not include a declaration of ranges::iter_swap. If the function selected by overload resolution does not exchange the values denoted by E1 and E2, the program is ill-formed with no diagnostic required.template<class I1, class I2> void iter_swap(I1, I2) = delete;
It is not intentional design that users may customize the behavior of ranges::iter_move ([iterator.cust.move]) and ranges::iter_swap ([iterator.cust.swap]) for pointers to program-defined type by defining e.g. iter_move(my_type*) or iter_swap(my_type*, my_type*) in a namespace associated with my_type. The intent of customization points is that users may define behavior for types they define, not that users may mess with the well-defined semantics for existing types like pointers.
We should forbid such silliness by constraining the "finds an overload via ADL" cases for customization points to only trigger with argument expressions of class or enumeration type. Note that WG21 made a similar change to ranges::swap shortly before merging it into the working draft to forbid users customizing behavior for pointers to program-defined types or arrays of program-defined types.
|2019-10-07 21:12:50||admin||set||messages: + msg10688|