I was pointed out to the fact that identifiers in attributes might be suffering from a similar wording defect. Given that they are explicitly exempted from undergoing name lookup, maybe they shouldn't be considered names either.

The more radical approach to fixing both issues would be to merge p3 and p5, saying that the grammar productions from p3 are names when they are a part of declarations listed in p5. This would eliminate all defects along the lines "it's an identifier, hence a name per p3, but it doesn't fit what p5 says."

I think it would be better to make p5 less restrictive.

5. Every name is introduced by a declaration, which A declaration that introduces a name is a
   [...]

No. Labels are not names (because they are not subject to name lookup).

@jensmaurer I still think @frederick-vs-ja 's suggestion would be an improvement here!

I think it would be better to make p5 less restrictive.

5. Every name is introduced by a declaration, which A declaration that introduces a name is a
   [...]

Wouldn't this make label a name, because it satisfies p3?

CWG2992

I think the conceptual model after P1787R6 is:

1. An identifier is a name whether it is introduced by a declaration or not.
2. In most cases, a name must be introduced by a declaration for it to be meaningfully used. In particular, name lookup usually requires a declaration to exist (http://eel.is/c++draft/basic.lookup.general#1.sentence-3).
3. Certain other constructs also require a declaration to exist. For example, a declaration with a qualified-id requires a previous declaration.
4. In other cases, a name does not need to have a declaration.

Now, uses of identifier labels do not interfere with declarations or name lookup. The fact that an identifier is a name does not matter at all.

This means [basic.pre]/3 is fine, but [basic.pre]/5 is problematic.

Every name is introduced by a declaration

Here is another example which shows that [basic.pre]/5 is problematic:

auto f(auto a) { g(a); }

g is a name (and it is subject to name lookup), but it is not introduced by a declaration and doesn't need to as long as f is not instantiated.

I disagree; I want the inverse approach. Labels and attributes are simply not names, and any statement to the contrary needs to be fixed.

For your g example, if g is never declared, then the program is IFNDR, because no valid specialization can be generated from the template. So, we do need a declaration of g somewhere.

I disagree; I want the inverse approach. Labels and attributes are simply not names, and any statement to the contrary needs to be fixed.

Then we need to turn https://eel.is/c++draft/dcl.attr#grammar-4.sentence-6 into a note, and say that identifiers within attribute-specifiers are not names, too.

I disagree; I want the inverse approach. Labels and attributes are simply not names, and any statement to the contrary needs to be fixed.

Why do you care if they are names or not? It doesn't matter at all.

For your g example, if g is never declared, then the program is IFNDR, because no valid specialization can be generated from the template. So, we do need a declaration of g somewhere.

Let's suppose that auto f(auto a) { g(a); } is exported from a module mod_a. A valid specialization can be generated by:

1. Define a type struct A { friend void g(A) {} }, and export it from an unrelated module mod_b.
2. Create a TU file_c.cpp that imports both mod_a and mod_b. Then
3. Instantiate f<A> in file_c.cpp.

This doesn't cause the name g to be introduced when compiling mod_a.

I do care because I don't want "names" to exist that are not declared and/or not subject to name lookup. I find it a more consistent overall picture to have a "name" only where that implies a connection to name lookup.

Regarding g: Sure, but what's your point? I'm saying the program needs to have a declaration of g somewhere. You're saying that declaration might be in a different module. I agree, but that's still in the same program.

1. Can a valid specialization be generated, if it is possible to generate one in a few steps, but these steps are not actually performed?
2. Regardless of 1, could the presence of an unreachable declaration affect the validity of a template in an unrelated module?

1. Can a valid specialization be generated, if it is possible to generate one in a few steps, but these steps are not actually performed?
2. Regardless of 1, could the presence of an unreachable declaration affect the validity of a template in an unrelated module?

It seems to me that this example shows an unfortunate fact: theoretically, the validness of this function template can't be determined locally, and we can only consider well-formedness of the whole program in this case.