public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: waffl3x <waffl3x@protonmail.com>
To: Jason Merrill <jason@redhat.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH v8 1/4] c++: P0847R7 (deducing this) - prerequisite changes. [PR102609]
Date: Tue, 09 Jan 2024 23:59:40 +0000	[thread overview]
Message-ID: <9feBwY_dKikUsVPK1ABZ8GNsRlkcIPi-qMfAlhgiRzC8FbBa3jHdaW8NpILUrXxC8BjGPJKNis_-9iWrRDh3nV5DQV6kilFVWbG-qEokHfg=@protonmail.com> (raw)
In-Reply-To: <f65a41dd-9c19-415f-924b-4cba5bf889d8@redhat.com>






On Tuesday, January 9th, 2024 at 3:52 PM, Jason Merrill <jason@redhat.com> wrote:


> 
> 
> On 1/9/24 17:34, waffl3x wrote:
> 
> > On Tuesday, January 9th, 2024 at 2:56 PM, Jason Merrill jason@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


  reply	other threads:[~2024-01-09 23:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-07  0:00 waffl3x
2024-01-09 20:58 ` Jason Merrill
2024-01-09 21:26   ` waffl3x
2024-01-09 21:56   ` Jason Merrill
2024-01-09 22:34     ` waffl3x
2024-01-09 22:52       ` Jason Merrill
2024-01-09 23:59         ` waffl3x [this message]
2024-01-10 17:15 ` Patrick Palka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='9feBwY_dKikUsVPK1ABZ8GNsRlkcIPi-qMfAlhgiRzC8FbBa3jHdaW8NpILUrXxC8BjGPJKNis_-9iWrRDh3nV5DQV6kilFVWbG-qEokHfg=@protonmail.com' \
    --to=waffl3x@protonmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).