On Thu, Mar 13, 2025 at 4:15 AM lh gkjhg via Std-Proposals <
std-proposals_at_[hidden]> 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.


>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*