Subject: Re: [std-proposals] Operator functions to fix ADL
From: ÐÑÐ¸Ð³Ð¾ÑÐ¸Ð¹ Ð¨ÑÑÐµÐ½ÐºÐ¾Ð² (grigorij1981_at_[hidden])
Date: 2020-10-12 10:58:50
This response was not sent to the list as well.
Ð²Ñ, 11 Ð¾ÐºÑ. 2020 Ð³. Ð² 22:52, ÐÑÐ¸Ð³Ð¾ÑÐ¸Ð¹ Ð¨ÑÑÐµÐ½ÐºÐ¾Ð² <grigorij1981_at_[hidden]>:
> 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.
> Ð²Ñ, 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
>> 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
>> 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Ã©.
>> On Oct 11, 2020, at 10:15 AM, ÐÑÐ¸Ð³Ð¾ÑÐ¸Ð¹ Ð¨ÑÑÐµÐ½ÐºÐ¾Ð² via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>> 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,
>> 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.
>> Std-Proposals mailing list
STD-PROPOSALS list run by email@example.com
Standard Proposals Archives on Google Groups