C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Add more methods to std::initializer_list instead of overloading

From: blacktea hamburger <greenteahamburger_at_[hidden]>
Date: Mon, 12 Sep 2022 19:53:29 +0800
My last email gave the reason (although the problems are different, the
reason is the same).

I don't understand why this guarantee is needed, is it important to
generate an error if x::f is not provided? If you want x.f() to force a
call to x::f, why not provide it because it selects a free function only if
there is no corresponding member function?

On Mon, Sep 12, 2022 at 7:52 PM blacktea hamburger <
greenteahamburger_at_[hidden]> wrote:

> My last email gave the reason (although the problems are different, the
> reason is the same).
>
> I don't understand why this guarantee is needed, is it important to
> generate an error if x::f is not provided? If you want x.f() to force a
> call to x::f, why not provide it because it selects a free function only if
> there is no corresponding member function?
>
> On Mon, Sep 12, 2022 at 7:38 PM Ville Voutilainen <
> ville.voutilainen_at_[hidden]> wrote:
>
>> On Mon, 12 Sept 2022 at 14:33, blacktea hamburger via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>> >
>> > Making a private member function public and overload resolution for
>> users and friends different won't cause problems as I said.
>>
>> We're veering off-topic.. I don't see where you explain how it won't
>> cause problems.
>>
>> > For the biggest problem you said, "TwoRoundsPreferAsWritten" can be
>> chosen so that if x.f() is used, x::f will be preferred to avoid ADL.
>>
>> That doesn't help at all. Currently, x.f() will never call a free
>> function, no matter what you do. That's an advantage,
>> and a guarantee that API designers rely on.
>>
>

Received on 2022-09-12 11:53:56