Re: [PATCH v8 1/4] c++: P0847R7 (deducing this) - prerequisite changes. [PR102609]

[waffl3x <waffl3x@protonmail.com>]

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


> 
> 
> On 1/9/24 15:58, Jason Merrill wrote:
> 
> > On 1/6/24 19:00, waffl3x wrote:
> > 
> > > Bootstrapped and tested on x86_64-linux with no regressions.
> > > 
> > > I'm considering this finished, I have CWG2586 working but I have not
> > > included it in this version of the patch. I was not happy with the
> > > amount of work I had done on it. I will try to get it finished before
> > > we get cut off, and I'm pretty sure I can. I just don't want to risk
> > > missing the boat for the whole patch just for that.
> > > 
> > > There aren't too many changes from v7, it's mostly just cleaned up.
> > > There are a few though, so do take a look, if there's anything severe I
> > > can rush to fix it if necessary.
> > > 
> > > That's all, hopefully all is good, fingers crossed.
> > 
> > Great. Given where we are in the release cycle, I'm thinking to put
> > these with only minimal changes and then do any further adjustments
> > afterward.
> > 
> > For this first one, I needed to fix the commit message to wrap at 75
> > columns so that it fits in 80 columns with the initial padding added by
> > 'git log'. I also needed to adjust the ChangeLog entry to please git
> > gcc-verify. And I changed the credit note to a Co-authored-by.
> > 
> > The other commit messages only needed wrapping.
> 
> 
> I just pushed your patches along with these two follow-ons:

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.

I have no objection to changing the comment in
iobj_xobj_parameters_correspond if you have a better idea on how to fix
the bug that inspired that comment. Especially since the standard is on
your side for it.

In this case, perhaps the comment should instead say something along
the lines of "this function does not account for using declarations."
That does get a little hairy though if both an iobj and xobj member
function are introduced by a using declaration. Perhaps we should just
optionally take a type that we can compare against? That sounds really
icky, maybe the solution you have in mind will work just fine.

BTW, I definitely assumed TYPE_MAIN_VARIANT was what I wanted in other
places in the patch, so there might be latent errors waiting to happen.
It's probably fine because those areas where I used them are pretty
well tested, but I thought it would be worth mentioning just in case.

I'm very excited to see this get through, thanks again for all the help
and patience.

Alex