[basic.scope.scope] Whether two types are distinct/same is underspecified in this document

[xmh0511]

Full name of submitter (unless configured in github; will be published with the issue): Jim X

[basic.scope.scope] p5 says

Two declarations potentially conflict if they correspond and cause their shared name to denote different entities ([basic.link]). The program is ill-formed if, in any scope, a name is bound to two declarations that potentially conflict and one precedes the other ([basic.lookup]).

Consider this example

struct X{};  // #1
typedef int X;  // #2

typedef void f(int);  // #3
typedef void f();  // #4

The names in #1 and #2 both denote a kind of entity called type. The same is true for #3 and #4. However, we do not have sufficient rules in this document that clearly say they are considered distinct types. In other words, what is the principle to say whether two types are the same or not?

Furthermore, for this case

struct X{};
enum X{};

[basic.link] p11 says

For any two declarations of an entity E:

• [...]
• If one declares E to be a type, the other shall declare E to be a type of the same kind ([dcl.type.elab]).

It could arguably say the meaning of "the same kind" is a bit unclear.

[frederick-vs-ja]

Is the taxonomy in [basic.types] not mutually exclusive enough to indicate

• int is not a class type, or
• a fundamental type is not a compound type?

[xmh0511]

Is the taxonomy in [basic.types] not mutually exclusive enough to indicate

Consider this example

typedef void f(int);  // #1
typedef void f();  // #2

they are all so-called "compound type", which principle sufficiently clarifies they are not the same type?

[frederick-vs-ja]

I think [dcl.fct]/1 and /2 are sufficient to indicate that different parameter-type-lists result in different function types.

[xmh0511]

I think [dcl.fct]/1 and /2 are sufficient to indicate that different parameter-type-lists result in different function types.

That must be established by we have defined a rule that can convey:

the type named "function of (int) returning void" distincts to "function of () returning void".

[FrankHB]

A slightly different but more general problem would be: where to find the rules to determine the identity of entities? Ideally they should be along with the rules for names in [basic.pre]; but there is nothing at current.

The problem raises in particular for types, because rules about types look more fragile, esp. with issues like https://cplusplus.github.io/CWG/issues/2584.html. It may be surprising enough that such rules are not in [basic.types], either. Moreover, the semantic properties implied by the rules are directly relied on by library facilities in [meta.rel] like std::is_same, whose meaning is not formally clear without these rules.

[xmh0511]

where to find the rules to determine the identity of entities?

Agree, that's also a status quo that, for a variable to which which object(a kind entity) corresponds, which is not clear, which would need the identity of the object to clarify. Maybe, the identity of a type is simpler to be clarified than that of an object. As you pointed out, the identity of every kind of entity is a wider and more generalized issue than the concerned things in this issue.