https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99931
Nathaniel Shead <nshead at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nshead at gcc dot gnu.org
--- Comment #2 from Nathaniel Shead <nshead at gcc dot gnu.org> ---
I believe that GCC's current behaviour is correct, by the current wording of
the standard. https://eel.is/c++draft/dcl.typedef#2 says, in full:
> A typedef-name can also be introduced by an alias-declaration.
> The identifier following the using keyword is not looked up;
> it becomes a typedef-name and the optional attribute-specifier-seq
> following the identifier appertains to that typedef-name.
> Such a typedef-name has the same semantics as if it were introduced
> by the typedef specifier.
So in 'using Foo = struct {};', the 'Foo' is a typedef-name with the same
semantics as if it was a typedef-name introduced by a typedef declaration.
However, note that the rules for having a typedef-name for linkage purposes
says explicitly (https://eel.is/c++draft/dcl.typedef#4):
> An unnamed class or enumeration C **defined in a typedef declaration**
> has the first typedef-name declared by the declaration to be of type C
> as its typedef name for linkage purposes ([basic.link]).
(emphasis mine)
That is, the typedef-name being for acquired for linkage purposes is
specifically due to being defined in a typedef declaration (not an
alias-declaration). The fact that I can create additional typedef-names
referring to C in other ways doesn't mean that they grant that name for linkage
purposes, e.g.:
struct {} s;
typedef decltype(s) Foo;
would also not give 's' a typedef name for linkage purposes despite having
provided a typedef-name 'Foo'.
Of course, maybe this is a defect in the standard wording and this is not the
intended behaviour (though this feature is primarily for C compatibility, I
would think, so it wouldn't surprise me if this is intended).
