Sorry, my email keeps getting the wrong recipient and I forget to change it
back.

The only thing they (free functions in some hidden corner) can do is make
otherwise wrong code compile. If you provide a member function (as long as
it makes the call legal) then the free functions will *never* be selected.

Private members not participating in the user's overload resolution will
also only make wrong code compile, because now an error will be generated
if the overload resolution selects a private member function.

On Mon, Sep 12, 2022 at 7:56 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:

> On Mon, 12 Sept 2022 at 14:53, blacktea hamburger via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > My last email gave the reason (although the problems are different, the
> reason is the same).
>
> Then we must agree to disagree whether that's a sufficient explanation for
> it.
>
> > 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?
>
> Because it's useful to be able to guarantee that authors outside your
> class hierarchy can't affect your calls, and that
> in particular, ADL calls never happen. It avoids surprises in overload
> resolution, and keeps the code meaning the same
> over refactorings elsewhere, without having to worry that someone else
> in a distant location in code that you don't even
> own changes the overload resolution result.
>