On Friday, December 1st, 2023 at 9:52 AM, Jason Merrill <ja...@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.
>
> Jason
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.
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?
Anyway while I do think this behavior is bad (not wrong according to
the standard, but bad imo), I recognize I don't have time to think
about it right now so I'll go back to working on the patch for the time
being.
Alex
