[lex] Reserved preprocessing-tokens *can* be conditionally used in the program

[TymianekPL]

In addition, some identifiers appearing as a token or preprocessing-token are reserved for use by C++ implementations and shall not be used otherwise; no diagnostic is required.

[lex.name]/3

3. The source file is decomposed into preprocessing tokens ([lex.pptoken]) and sequences of whitespace characters (including comments). A source file shall not end in a partial preprocessing token or in a partial comment.9 Each comment ([lex.comment]) is replaced by one U+0020 space character. New-line characters are retained. Whether each nonempty sequence of whitespace characters other than new-line is retained or replaced by one U+0020 space character is unspecified. As characters from the source file are consumed to form the next preprocessing token (i.e., not being consumed as part of a comment or other forms of whitespace), except when matching a c-char-sequence, s-char-sequence, r-char-sequence, h-char-sequence, or q-char-sequence, universal-character-names are recognized ([lex.universal.char]) and replaced by the designated element of the translation character set ([lex.charset]). The process of dividing a source file's characters into preprocessing tokens is context-dependent.
   [Example 1: See the handling of < within a #include preprocessing directive ([lex.header], [cpp.include]). — end example]
4. The source file is analyzed as a preprocessing-file ([cpp.pre]). Preprocessing directives ([cpp]) are executed, macro invocations are expanded ([cpp.replace]), and _Pragma unary operator expressions are executed ([cpp.pragma.op]). A #include preprocessing directive ([cpp.include]) causes the named header or source file to be processed from phase 1 through phase 4, recursively. All preprocessing directives are then deleted. Whitespace characters separating preprocessing tokens are no longer significant.

[lex.phases]/3,4

Each and every preprocessing-token is used in the translation before the 4th translation phase which executes preprocessing directives such as #ifdef.

Why is this a defect? You cannot use and query names like __cplusplus or feature-test macros, since these are preprocessing-tokens (not tokens) reserved for use by C++ implementations, and therefore shall not be used within a program. With such definition, this program is ill-formed (no diagnostics required):

#include <print>

int main()
{
     #if __cplusplus >= 202302L
     std::print("Hello C++23 and beyond!");
     #endif
}

I don't think this is the desired behaviour.

[YexuanXiao]

In addition, some identifiers appearing as a token or preprocessing-token are reserved for use by C++ implementations and shall not be used otherwise; no diagnostic is required.
...
other than those specified in this document (for example, __cplusplus ([cpp.predefined]))

[TymianekPL]

Still applies to macros like _WIN32 (predefined by the implementation).

[YexuanXiao]

"shall not be used otherwise" means that implementations may define them as needed and specify how they should be used, and consumers (user code) should not define them. (Please correct me if I have misunderstood.)

[jensmaurer]

Still applies to macros like _WIN32 (predefined by the implementation).

Right, and no portable program shall use such a macro. Which is exactly what we want to say.

[TymianekPL]

"shall not be used otherwise" means that implementations may define them as needed and specify how they should be used, and consumers (user code) should not define them. (Please correct me if I have misunderstood.)

No it means you cannot use these macros/names. All programs that use them are ill-formed, even in #ifdef.

[TymianekPL]

Still applies to macros like _WIN32 (predefined by the implementation).

Right, and no portable program shall use such a macro. Which is exactly what we want to say.

I'd rather not have my programs be ill-formed, but the behaviour be unspecified when using these names.

[TymianekPL]

Or at least implementation defined. Just because a program is not portable (is dependent on implementation defined behaviour) doesn't make it ill-formed.

[jensmaurer]

... shall not be used otherwise; no diagnostic is required.

means IFNDR, which means your program is no longer governed by the rules of the C++ standard, at all. See [intro.compliance.general] p2.2

Which, again, is exactly what we want when you use _WIN32 or similar; it seems too much of a burden for an implementation to require documenting its detailed behavior for these platform-specific macros.

In any case, this does not appear to be an editorial issue. Further, I'm not seeing a wording defect at the level of a core issue. If you wish to have the normative requirements changed (e.g. add a documentation requirement), then this should be submitted as a paper to EWG. https://isocpp.org/std/submit-a-proposal

[TymianekPL]

What about this program:

int main()
{
     assert(true);
}

Is this ill-formed (no diagnostics required)?
The implementation can and will use a reserved name for whatever assert expands into, and the definition says you cannot use tokens that are reserved. Or perhaps this is an implementation detail and no longer in the scope...? Just want to make sure this is the intended behaviour.

[YexuanXiao]

The assert macro must be implemented using reserved identifiers to prevent accidentally finding user-declared identifiers when parsing the expanded expression.