On Tuesday, January 9th, 2024 at 3:52 PM, Jason Merrill <ja...@redhat.com>
wrote:
>
>
> On 1/9/24 17:34, waffl3x wrote:
>
> > On Tuesday, January 9th, 2024 at 2:56 PM, Jason Merrill ja...@redhat.com
> > wrote:
> >
> >
> > Is the type of an implicit object parameter specified elsewhere? I have
> > looked for it more than once and I could only find that passage, but I
> > guess [over.match.funcs-1] is what I missed here, so
> > [over.match.funcs-4] doesn't apply elsewhere.
>
>
> That's the only definition I know of. And indeed my statement was
> wrong, it also affects the considerations in add_method. But I still
> think it would be more complicated in more places to deal with proxy
> FUNCTION_DECLs (like we do for inheriting constructors).
You would know the code base better than I, so you're probably right.
The code in add_method probably already handles it just fine, the only
caveat being that it needs corresponding object parameters when
deciding to discard an overload introduced by a using declaration...
uhoh yeah that might not be okay. This probably results in ambiguous
overload resolution, I'll throw together a test case to see if I can
confirm this...
struct B {
void f() {}
};
struct S : B {
using B::f;
void f(this S&) {}
};
int main() {
S s{};
s.f();
}
And yep, you're right, add_method is going to need to care about this
too. In the above test case, the call to f is incorrectly ambiguous.
The overload of f introduced by the using declaration should have been
discarded as the object parameters should correspond.
struct S;
struct B {
void g(this S&) {}
};
struct S : B {
using B::g;
void g() {}
};
int main()
{
S s{};
s.g();
}
While this case works correctly, the overload of g introduced by the
using declaration is correctly discarded.
Hopefully it's not too annoying to solve, I'm not exactly sure how to
go about it (other than the method you've already turned down) so I'll
leave it to you.
Alex
