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.