For some reason I did not send my response to the list, so I am resending
it.

Regards,


вс, 11 окт. 2020 г. в 23:15, Григорий Шуренков <grigorij1981_at_[hidden]>:

> I was not suggesting deprecating for complete removal, just limiting it
> in some distant release of the language to those cases that actually need
> ADL. Might be "deprecate" is too strong a word for what I am proposing.
>
> Regards,
> Gregory
>
> вс, 11 окт. 2020 г. в 22:49, Barry Revzin <barry.revzin_at_[hidden]>:
>
>>
>>
>> On Sun, Oct 11, 2020 at 9:16 AM Григорий Шуренков via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> Hi!
>>>
>>> C++ has rather complex name lookup rules for unqualified function calls
>>> that involve argument-dependent lookup and may lead to surprising results.
>>> And from time to time there appear proposals to fix those rules. This is
>>> one of such proposals.
>>>
>>> Most of the time invoking ADL is not what a user wanted. However, ADL
>>> also has legitimate use cases: operators and "customization points" (swap,
>>> begin, end are examples). The idea of the proposal is that we can mark
>>> customization points with *operator* keyword and deprecate ADL for all
>>> functions that are not marked with such keyword.
>>>
>>
>> We can't deprecate ADL, we're never going to remove it - there's too much
>> code that depends on its existence and there is little benefit to changing
>> it
>>
>>
>>>
>>> That is if ADL was triggered for an unqualified function call and a
>>> function was found via ADL that was not an *operator, *then a compiler
>>> may issue a warning. Currently it's not feasible to have such a warning,
>>> because we cannot not discriminate between "good" ADL and "bad" ADL.
>>>
>>> Declaration of a custom swap function then will look like this:
>>> void operator swap (A& fst, A& snd);
>>>
>>> There are other things that might be included in the proposal:
>>> 1) requesting ADL via operator keyword at the call-site: operator
>>> swap(a, b);
>>> 2) searching "operator functions" among class members, thus allowing
>>> uniform function call syntax at least for them.
>>> But before exploring those directions further I would like to get
>>> feedback on the main idea.
>>>
>>> Regards,
>>> Gregory
>>>
>>
>> Marking customization points is certainly worthwhile - to have a more
>> refined lookup mechanism than whatever is in a namespace. I really like
>> Matt Calabrese's idea here in P1292:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1292r0.html.
>> You declare a function as being customizeable, and you declare your
>> functions that customize it. That way, you wouldn't have to annotate the
>> call-site or provide a separate library mechanism to do dispatch.
>>
>> Barry
>>
>>
>