Title
ranges::iter_move should perform ADL-only lookup of iter_move
Status
new
Section
[iterator.cust.move]
Submitter
Casey Carter

Created on 2019-07-29.00:00:00, last changed 2019-08-04.18:56:46.

Messages

Date: 2019-08-04.18:56:46

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".]

  1. Modify [iterator.cust.move] as indicated:

    -1- The name ranges::iter_move denotes a customization point object ([customization.point.object]). The expression ranges::iter_move(E) for some subexpression E is expression-equivalent to:

    1. (1.1) — iter_move(E), if that expression is validwell-formed when treated as an unevaluated operand, with overload resolution performed in a context that does not include a declaration of ranges::iter_move. but does include the declaration:

         void iter_move();
      
    2. […]

Date: 2019-07-29.00:00:00

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.

Absent a more idiomatic wording to specify an ADL-only lookup, we can correct the problem by specifying the lookup in paragraph 1.1 is performed in a context that includes the declaration "void iter_move();" which has the desired effect.

History
Date User Action Args
2019-08-04 18:56:46adminsetmessages: + msg10540
2019-07-29 00:00:00admincreate