pon., 20 lip 2020 o 21:54 Matthew Woehlke via Std-Proposals
<std-proposals@lists.isocpp.org> 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