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

[waffl3x <waffl3x@protonmail.com>]

Hey Jakub, thanks for the response
and criticism, as soon as I am
back at a computer I will address
the issues you raised, I have a few
questions though.

I apologize in advanced for any
errors in formatting this message,
I'm writing it from a hotel room
on a phone so errors are inevitable,
but I'll try my best.

>More importantly, should describe
>what changed and not why
I was under the impression that
if someone wants to see the what,
they can just check the diff.
I don't understand what should be
written if I'm just to say what,
wouldn't I just be repeating what
is already said in the code itself?

>I think usually we don't
>differentiate
>in testcase names whether
Yeah, for sure, but I felt like
there is value in differentiating
them and that it would be harmless
to do so. If you feel like it's
more important that convention is
followed here I won't object, but I
think this should be considered.

>Isn't explicit-object-param too long
>though?
>explicit-this or deducing-this might
>be shorter...
I agree, but I felt like I should
stick to the wording of the standard
for it, but I don't feel strongly
about that justification, so I
wouldn't object to changing it.
Truthfully I flip flopped many
times around the names, I'll defer
to whatever is decided by the
maintainers on that without complaint.

>> +}
>> \ No newline at end of file
>Please avoid these
Yeah, I noticed it last minute and
wasn't sure how big a deal it was.
I will make sure to fix it along
with everything else you noted.

>Usually runtime tests don't try to
>print something
Yeah, I didn't like printing, but
I'm not sure I like aborting either.
I value granularity in testing, if
one part of the test passes but
another fails, you would want to know
that. If you abort before the second
you lose that granularity.
Once again, I'll defer to the
maintainers for this, but I think
my points are valid here.

>This raises an important question whether we as an extension
>should support deducing this even in older standards or not.
>I admit I haven't studied the paper enough to figure that out.

I'm glad you think so, I fully agree.
I had planned to raise that once
the initial patch made it in. I don't
believe there is anything in the paper
in particular that breaks previous
standards.
I can imagine there being problems
if older projects tried to convert
everything to use it as there are
alignment differences (at least in
the current patch version) between
explicit object member functions and
implicit object member functions.
This is mostly a side effect of
treating them as static functions
most of the time, but I wasn't sure
what would be ideal, nor how to change
it. I decided that the difference
was likely mainly due to virtual
functions (if you know more about
this, please be sure to correct me),
and as virtual is not
(currently) allowed, I just left it
as it is.
In short, I agree, and furthermore
I think the syntax should be allowed
with virtual just so style can
be maintained. That would have greater
implications than what you mentioned
though and would need some extra
hacks to make work, instead of just
allowing what should -just- work.

Thanks again for the input, I will
get on it asap. Unfortunately that
will be in a while, but I am
determined to get this feature into
GCC14 so one way or another I will
make it happen.

-Alex