Subject: Re: [std-proposals] Std-Proposals Digest, Vol 19, Issue 17
From: Tjernstrom, Staffan (Staffan.Tjernstrom_at_[hidden])
Date: 2020-10-12 08:15:04
> 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, b);
As one of the "I am just a regular user, not a compiler guru" lurkers on this list, I'd just like to mention that anything that involves call-site annotation is a great source of confusion for regular users, especially when the answer to "Why?" is "obscure reason X" as it would be in this case. Shifting the responsibility to the caller is just as ineffective as documenting the issue in a manual.
I think the problem is that we have a tradition of writing C++ not caring about the users of that code. We shouldn't try to fix that in the langauge, but rather in the community (but that's a different lightning talk).
> 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.
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
STD-PROPOSALS list run by email@example.com
Standard Proposals Archives on Google Groups