This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115g. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-12-16
[Accepted at the November, 2020 meeting as part of paper P1787R6 and moved to DR at the February, 2021 meeting.]
According to 6.6 [basic.link] paragraph 9,
Two names that are the same (6.1 [basic.pre]) and that are declared in different scopes shall denote the same variable, function, type, enumerator, template or namespace if
both names have external linkage or else both names have internal linkage and are declared in the same translation unit; and
both names refer to members of the same namespace or to members, not by inheritance, of the same class; and
when both names denote functions, the parameter-type-lists of the functions (9.3.4.6 [dcl.fct]) are identical; and
when both names denote function templates, the signatures (13.7.7.2 [temp.over.link]) are the same.
This is not as clear as it should be. The intent is that this rule prevents declaring a name with extenal linkage to be, for instance, a type in one translation unit and a namespace in a different translation unit. It has instead been read as begging the question of what it means for two entities to be the same. The wording should be tweaked to make the intention clear. Among other things, it should be clarified that "declared in" refers to the namespace of which the name is a member, not the lexical scope in which the declaration appears (which affects friend declarations, block-scope extern declarations, and elaborated-type-specifiers).
There is a similar restriction in _N4868_.6.4.1 [basic.scope.declarative] paragraph 4 dealing with declarations within a single declarative region, while 6.6 [basic.link] paragraph 9 deals with names that are associated via linkage. The relationship between these complementary requirements may need to be clarified as well.
See also issue 2165.
Additional note, March, 2019:
6.6 [basic.link] paragraph 11 concludes by saying,
A violation of this rule on type identity does not require a diagnostic.
Presumably a diagnostic should be required if the differing types appear within a single translation unit.