Making a public member function private will not cause a problem, because
it will cause an error if a private member function (better) is selected.
With such workaround only the error code will compile.

On Mon, Sep 12, 2022 at 6:13 PM 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 for the newly added public member functions... There seems to be no
> way.
> >
> > But it does do more good than bad, i.e. less functions and no need to
> > worry about whether x.f() or f(x) should be used.
> >
> > On Sun, Sep 11, 2022 at 11:16 PM Jason McKesson via Std-Proposals
> > <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
>
> > wrote:
> >
> > On Sun, Sep 11, 2022 at 10:47 AM blacktea hamburger via Std-Proposals
> > <std-proposals_at_[hidden]
> > <mailto:std-proposals_at_[hidden]>> wrote:
> > >
> > > So the standard library needs a cleanup, hopefully someone will
> > push it forward when the UFCS arrives.
> >
> > You know that UFCS is not gonna happen, right? Or was that the joke?
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>