That is separable functionality that we will revisit in a future paper with
explicit syntax to enable it.

I'm sure adding yet another overload to ADL without an opt-out is a
non-starter with ewg, and I would never propose that myself either.

G

On Mon, Jul 20, 2020, 21:53 Marcin Jaczewski via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> pon., 20 lip 2020 o 22:42 Barry Revzin <barry.revzin_at_[hidden]>
> napisał(a):
> >
> >
> >
> > On Mon, Jul 20, 2020 at 3:22 PM Marcin Jaczewski via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >>
> >> pon., 20 lip 2020 o 21:54 Matthew Woehlke via Std-Proposals
> >> <std-proposals_at_[hidden]> napisał(a):
> >> >
> >> > On 20/07/2020 08.43, Magnus Fromreide via Std-Proposals wrote:
> >> > > When calling a deduced this member
> >> > >
> >> > > instance.deduced_this_member(a, b);
> >> > >
> >> > > then that is interpreted as
> >> > >
> >> > > deduced_this_member(instance, a, b);
> >> > >
> >> > > This looks exactly like what N4165 proposed albeit restricted to
> only
> >> > > deduced this members and that is why I asked. It could very well be
> that
> >> > > limiting it to only deduced this members solves all the problems.
> >> >
> >> > Er... yes and no. The difference is, what you wrote is how C++ has
> >> > *always* worked, with the caveat that you don't "see" the 'instance'
> >> > argument in a member function (except as `this`).
> >> >
> >> > The difference you are possibly overlooking is that
> >> > `deduced_this_member` is still a *member* function, with all the
> >> > limitations and other attributes thereof. UFCS is about being able to
> >> > substitute *free* functions. P0847, OTOH, is just making the
> previously
> >> > implicit `this` argument more exposed (a bit like Python), with
> >> > additional fiddly-bits to make said exposure more useful.
> >> >
> >> > Really, though, it's that "still a member function" that's important.
> A
> >> > lot of the issues with UFCS deal with knowing whether you're calling a
> >> > member or a free function, and the ability to arbitrarily introduce
> >> > matching free functions. So, yes, "limiting it to only deduced this
> >> > members solves all the problems" is probably (at least mostly)
> accurate.
> >> >
> >>
> >> No, this functions are not member functions, you can't use them as
> >> member functions because of case like `void f(this T);` what member
> >> function pointer type is this?
> >
> >
> > Yes, these functions are member functions and you can use them as member
> functions. The type of f here, assuming it's in the middle of a class
> (otherwise it would be ill-formed), is void(*)(T). In the same way that the
> type of a pointer to a static member function is also a pointer to function.
> >
> > They're basically a hybrid between static and non-static member
> functions - static in the sense of the type and the lack of implicit this,
> and non-static in the sense of how invocation works.
> >
> >
> >>
> >>
> >> p0847r4:
> >> >>
> >> >> struct Y {
> >> >> int f(int, int) const&;
> >> >> int g(this Y const&, int, int);
> >> >> };
> >> >> While the type of &Y::f is int(Y::*)(int, int) const&, the type of
> &Y::g is int(*)(Y const&, int, int).
> >> >> As these are just function pointers, the usage of these two member
> functions differs once we drop them to pointers:
> >>
> >> This means we can drop last pretend and allow both call conventions.
> >
> >
> > If by "both call conventions", you mean to also Y::g(Y{}, 1, 2), then
> yes that already is valid as stated in the paper (because they're like
> static member functions) in the same way that Y{}.g(1, 2) is valid (because
> they're like non-static member functions).
> >
> > If what you mean is to allow g(Y{}, 1, 2), then... no.
> >
> > Barry
>
> That was my point, allow `g(Y{}, 3, 2)`, because what difference is to
> the definition of `friend int g(Y const&, int, int);`?
> Of course paper do not suggest this, but for me this is a logical
> conclusion. As this is op-in we do not have problems like other
> solutions had for that functionality.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>