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.
