This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++20 status.
ranges::iter_move
should perform ADL-only lookup of iter_move
Section: 25.3.3.1 [iterator.cust.move] Status: C++20 Submitter: Casey Carter Opened: 2019-07-29 Last modified: 2021-02-25
Priority: 2
View all other issues in [iterator.cust.move].
View all issues with C++20 status.
Discussion:
The specification of the ranges::iter_move
customization point in [iterator.cust.move]
doesn't include a deleted poison pill overload. There is no std::iter_move
to avoid,
so such a poison pill is not needed. This is fine, except that it suggests that unqualified
lookup for iter_move
in the iter_move(E)
expression in paragraph 1.1 should
find declarations of iter_move in the global namespace via normal unqualified lookup, when the
design intent is that only ADL be used to find overloads of iter_move
.
void iter_move();
" which has the desired effect.
[2020-02 Status to Immediate on Thursday morning in Prague.]
Proposed resolution:
This wording is relative to N4820.
[Drafting Note: There's a drive-by fix here to change "valid" — which suggests runtime behavior which cannot be validated at compile time — to "well-formed".]
Modify 25.3.3.1 [iterator.cust.move] as indicated:
-1- The name
ranges::iter_move
denotes a customization point object (16.3.3.3.5 [customization.point.object]). The expressionranges::iter_move(E)
for some subexpressionE
is expression-equivalent to:
(1.1) —
iter_move(E)
, if that expression isvalidwell-formed when treated as an unevaluated operand, with overload resolution performed in a context that does not include a declaration ofranges::iter_move
.but does include the declaration:void iter_move();[…]