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@gmail.com> wrote:
On Mon, 12 Sept 2022 at 14:53, blacktea hamburger via Std-Proposals
<std-proposals@lists.isocpp.org> 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.