This response was not sent to the list as well.

Regards,
Gregory

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

> Hi!
>
> Actually, maybe it's just a poor wording from my side. What I meant is the
> following, each time an unqualified function call is made ADL is performed.
> In order to not to perform ADL you'd need either to qualify it, or put
> function name in parentheses. In code bases I have worked with, most of
> unqualified function calls are supposed to just call a known function w/o
> involving argument-dependent lookup. It's true you can teach yourself to
> always qualify function calls, but most of the programmers I have worked
> with do not do that.
>
> So, by invoking ADL I do not mean that compiler actually finds something,
> but that it tries.
>
> Regards,
> Gregory
>
> вс, 11 окт. 2020 г. в 21:08, Jody Hagins <coachhagins_at_[hidden]>:
>
>> Hi Gregory.
>>
>> I knew Arthur would be the first to respond :-)
>>
>> I understand the general issues, andI am in favor of addressing some of
>> the issues surrounding naming and ADL. However, I would like to know why
>> you say "Most of the time invoking ADL is not what a user wanted" - for two
>> reasons.
>>
>> First, while I know there are issues, I certainly do not have this
>> experience - yes there are issues, but most of the time invoking ADL is
>> exactly what I wanted - it is those few startling times that I don't like.
>> So, I would like to better understand the issues that cause, in your
>> experience, for most usage to result in something unexpected since I'm
>> obviously missing something.
>>
>> Second, I've noticed a number of good proposals being taken down a
>> slippery slope merely because the reasoning could be considered
>> inflammatory, or in this case possibly exaggerated. Unless, of course, you
>> can give good reasoning to back the claim that "most of the time invoking
>> ADL is not what a user wanted," in which case that reasoning should be
>> presented rather than just a blanket statement that may otherwise derail
>> discussion.
>>
>> Hmmm... Maybe I'm the one taking it into a rabbit hole this time - I hope
>> not - but this group is partly for that purpose - to bring things up
>> informally so that once things are brought up more officially those things
>> will have already been addressed.
>>
>> In any case, I would love to know why you make that claim because I
>> obviously need to learn something in my naïveté.
>>
>> Thanks!
>>
>>
>>
>> On Oct 11, 2020, at 10:15 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.
>>
>> 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
>>
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>>
>>