On Thu, Mar 13, 2025 at 4:15 AM lh gkjhg via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
After P1787R5,  the working draft, e.g., N4892 in [basic.scope.scope], says:
Two declarations correspond if they (re)introduce the same name, both declare constructors, or both declare
destructors, unless
—(3.1) either is a using-declarator, or
—(3.2) one declares a type (not a typedef-name) and the other declares a variable, non-static data member
other than of an anonymous union (11.5.2), enumerator, function, or function template, or
—(3.3) each declares a function or function template, except when
—(3.3.1) both declare functions with the same parameter-type-list,21 equivalent (13.7.7.2) trailing requires-
clauses (if any, except as specified in 13.7.5), and, if both are non-static members, the same
cv-qualifiers (if any) and ref-qualifier (if both have one), or
—(3.3.2) both declare function templates with equivalent parameter-type-lists, return types (if any), template-
heads, and trailing requires-clauses (if any), and, if both are non-static members, the same
cv-qualifiers (if any) and ref-qualifier (if both have one).
While in N5001,clauses 6.4.1.3 and 6.4.1.4, wording is changed to use terms of corresponding object parameters
Two non-static member functions have corresponding object parameters if
—(3.1) exactly one is an implicit object member function with no ref-qualifier and the types of their object
parameters (9.3.4.6), after removing references, are the same, or
— (3.2) their object parameters have the same type.
It seems that N4892 and N5001 both agreed that two non-static member functions with different cv-qualifier, and in which
exactly one is with no ref-qualifer, are not corresponding.


However, in N4849 [over.load] 12.2.2.3, there is an example:
class Y {
    //... omit unrelated.
    void i() &;
    void i() const;  // error: prior declaration of i has a ref-qualifier
};
If I understand correctly, this example becomes well-form now, but different compilers have different behaviours.
GCC 14 and MSVC(v19.40) still reject this example code, while clang 20 and icx 2025 only accept this code in C++23 mode, but not in C++20 mode or others.

I'm not sure whether it is intended behavior or something breaking compatibility.
Annex C says nothing about these.


This list (std-proposals) is for proposals; you probably meant to send this message to std-discussion.

We don't add Annex C entries when ill-formed code becomes well-formed.

It is likely that GCC and MSVC have not fully implemented the new rules yet. Please file a bug report with GCC. I'm not seeing any issue with the standard here.
 


--
Brian Bi