[Bug c++/102609] [C++23] P0847R7 - Deducing this
waffl3x at protonmail dot com
gcc-bugzilla@gcc.gnu.org
Wed Jul 17 02:59:12 GMT 2024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #31 from waffl3x <waffl3x at protonmail dot com> ---
(In reply to Gašper Ažman from comment #30)
> I don't really understand what you meant by "they have corresponding object
> parameters" - you mean that the object parameters are equal in both
> constraint and type? "Corresponding" to my recollection is only used for
> argument-to-parameter correspondence, but I could be wrong.
https://eel.is/c++draft/basic.scope.scope#3
Correspond is used throughout here to refer to declarations. As far as
I can tell it doesn't get used outside of here, however, it does get
referenced in [over.match.oper]#4.
https://eel.is/c++draft/over.match.funcs#over.match.oper-4
Given this, I don't think it's a stretch to extend it's use into
over.match.best.
Now I'm not exactly an expert here and it's been a while since I read
through everything so I'm a little rusty. While I don't really know how
the wording for whether constraints can be taken into account on 2
function overloads goes, I can't imagine it's very far away from what
is specified for declaration correspondence.
This is basically all I can find here and I'm pretty sure it's not
relevant at all here.
https://eel.is/c++draft/temp.over.link#7.2
After a bunch of searching, I finally found where exactly it's
specified for function templates.
https://eel.is/c++draft/temp.func.order#6.2.2
They just say "same type" there, which is a problem. I don't think
anyone has written an issue regarding this yet so I might do so, not
that I know how to. :^)
I know for sure that Jason Merrill has suggested that CWG2789 be
changed to "corresponding object parameter" instead as I discussed this
with him when writing the patch. Even if it's a little weird to
reference basic.scope.scope in other parts of the standard, if we don't
implement it this way there are some oddities with overload resolution.
I wrote about this at length in these test cases.
gcc/testsuite/g++.dg/cpp23/explicit-obj-constraints.C
gcc/testsuite/g++.dg/cpp23/explicit-obj-constraints2.C
But, as I've discovered, I made a few mistakes here so I might go back
and revise it to note the motivations for treating it the way I did,
and how it doesn't currently follow the letter of the standard.
More information about the Gcc-bugs
mailing list