CWG 2022-11-11

A possible approach, in addition to the proposed resolution above, is to prohibit the [ and { pp-tokens in the controlling expression of a conditional inclusion. C++ also permits using the alternative tokens, e.g. not, which might need clarification in the wording.

Additional note (March, 2022):

The proposed resolution shown above allows lambda-expressions, which is undesirable.

Proposed resolution (February, 2012):

1. Change 15.2 [cpp.cond] paragraph 2 as follows:

Each preprocessing token that remains (in the list of preprocessing tokens that will become the controlling expression) after all macro replacements have occurred shall be in the lexical form of a token (5.10 [lex.token]). Any such token that is a literal (5.13.1 [lex.literal.kinds]) shall be an integer-literal, a character-literal, or a boolean-literal.

2. Change 15.2 [cpp.cond] paragraph 4 as follows:

...using arithmetic that has at least the ranges specified in 17.3 [support.limits]. The only operators permitted in the controlling constant expression are ?:, ||, &&, |, ^, &, ==, !=, <, <=, >, >=, <<, >>, -, +, *, /, %, !, and ~. For the purposes of this token conversion...

It appears that some of the recent changes to the description of constant expressions have allowed constructs into preprocessor expressions that do not belong there. Some changes are required to restrict the current capabilities of constant expressions to what is intended to be allowed in preprocessor expressions.