Date: Thu, 13 Mar 2025 08:15:20 +0000
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.
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.
Received on 2025-03-13 08:15:25