Making a private member function public and overload resolution for users
and friends different won't cause problems as I said.

For the biggest problem you said, "TwoRoundsPreferAsWritten
<https://brevzin.github.io/c++/2019/04/13/ufcs-history/#overload-resolution-rules>"
can be chosen so that if x.f() is used, x::f will be preferred to avoid ADL.

On Mon, Sep 12, 2022 at 6:17 PM Ville Voutilainen via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Mon, 12 Sept 2022 at 13:13, Bo Persson via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > On 2022-09-12 at 10:30, blacktea hamburger via Std-Proposals wrote:
> > > No, I am not joking. Why are you sure UFCS is impossible? Are there any
> > > relevant discussions?
> > >
> > > I do not think so, although it has problems described here
> > > <
> https://brevzin.github.io/c++/2019/08/22/ufcs-custom-extension/#why-not-ufcs>
> that it can be affected by newly added member functions. For newly added
> private member functions, the language rules can be modified so that they
> do not participate in overload resolution.
> >
> > So if I make one of the public members private, the overload resolution
> > should just select the second best overload instead?
> >
> > I can see some problems with that. :-)
>
> ..and having overload resolution be different for public users and
> friends has its own problems, and changing private
> members to public members and getting a completely different overload
> resolution result has other problems..
> UFCS is indeed riddled with problems. Striving for x.f() to be able to
> call f(x) has a whole lotta problems, the most
> drastic one being that right now, you can confidently design class
> hierarchy interfaces and calls into them with
> the knowledge that the ADL goblins will never bite you, but such a
> "membercallsyntax -> freefunction call" would
> remove that confidence.
>
> There's reasons why UFCS wasn't adopted, and I'm unaware of any
> current work striving to change that.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>