[PATCH v6 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609]

[Jason Merrill]

On 12/1/23 20:31, waffl3x wrote:
> On Friday, December 1st, 2023 at 9:52 AM, Jason Merrill <jason@redhat.com> wrote:
>> On 12/1/23 01:02, waffl3x wrote:
>>
>>> I ran into another issue while devising tests for redeclarations of
>>> xobj member functions as static member functions and vice versa. I am
>>> pretty sure by the literal wording of the standard, this is well formed.
>>>
>>> template<typename T>
>>> concept Constrain = true;
>>>
>>> struct S {
>>> void f(this auto, Constrain auto) {};
>>> static void f(Constrain auto) {};
>>>
>>> void g(this auto const&, Constrain auto) {};
>>> static void g(Constrain auto) {};
>>>
>>> void h(this auto&&, Constrain auto) {};
>>> static void h(Constrain auto) {};
>>> };
>>>
>>> And also,
>>>
>>> struct S{
>>> void f(this auto) {};
>>> static void f() {};
>>>
>>> void g(this auto const&) {};
>>> static void g() {};
>>>
>>> void h(this auto&&) {};
>>> static void h() {};
>>> };
>>>
>>> I wrote these tests expecting them to be ill-formed, and found what I
>>> thought was a bug when they were not diagnosed as redecelarations.
>>> However, given how the code for resolving overloads and determining
>>> redeclarations looks, I believe this is actually well formed on a
>>> technicality. I can't find the passages in the standard that specify
>>> this so I can't be sure.
>>
>>
>> I think the relevant section is
>> https://eel.is/c++draft/basic.scope.scope
>>
>>> Anyway, the template parameter list differs because of the deduced
>>> object parameter. Now here is the question, you are required to ignore
>>> the object parameter when determining if these are redeclarations or
>>> not, but what about the template parameters associated with the object
>>> parameter? Am I just missing the passage that specifies this or is this
>>> an actual defect in the standard?
>>
>>
>> I think that since they differ in template parameters, they don't
>> correspond under https://eel.is/c++draft/basic.scope.scope#4.5 so they
>> can be overloaded.
>>
>> This is specified in terms of the template-head grammar non-terminal,
>> but elsewhere we say that abbreviated templates are equivalent to
>> writing out the template parameters explicitly.
>>
>>> The annoying thing is, even if this was brought up, I think the only
>>> solution is to ratify these examples as well formed.
>>
>> Yes.
> 
> I can't get over that I feel like this goes against the spirit of the
> specification. Just because an object argument is deduced should not
> suddenly mean we take it into account. Too bad there's no good solution.

Yep.  Note that it's normal for a template to overload with a non-template:

struct A
{
   void f();
   template <class T> void f();  // OK
};

> I especially don't like that that the following case is ambiguous. I
> understand why, but I don't like it.
> 
> template<typename T>
> concept Constrain = true;
> 
> struct S {
>    int f(this auto, Constrain auto) {};
>    static f(auto) {};
> };
> main() {
>    S{}.f(0);
> }
>
> I would like to see this changed honestly. When an ambiguity is
> encountered, the more constrained function should be taken into account
> even if they normally can't be considered. Is there some pitfall with
> this line of thinking that kept it out of the standard? Is it just a
> case of "too hard to specify" or is there some reason it's impossible
> to do in all but the simplest of cases?

I would actually expect the static function to be chosen as more 
specialized before we get to considering constraints, just as with

void f(auto, Constrain auto) = delete;
void f(const S&, auto) {}
int main() { f(S{},0); } // OK

Though it looks like [temp.func.order] needs to be adjusted for explicit 
object parameters.  And more_specialized_fn in gcc still has an outdated 
handling of object parameters that just skips them, from before the 
clearer specification in C++11 and later; this is PR53499.  No need to 
address that preexisting bug in this patch.

Jason