Date: Mon, 12 Sep 2022 12:13:21 +0200
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?
> 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?
Received on 2022-09-12 10:13:30