- Notifications
You must be signed in to change notification settings - Fork803
[cpp.cond] Keywords are not identifiers while preprocessing#8518
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
[cpp.cond] Keywords are not identifiers while preprocessing#8518
Uh oh!
There was an error while loading.Please reload this page.
Conversation
source/preprocessor.tex Outdated
| \begin{note} | ||
| Keywords are identifiers during preprocessing and are not valid macro names, | ||
| so are always replaced by\tcode{0} before being converted into a token. | ||
| \end{note} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Do we need this note after we've removed "keyword" in the first place?
We do mention "true" and "false" as identifiers above, so there is a strong hint that phase 7 keywords are in view here.
If keywords were a separate thing, the note below would need to be amended with "keywords", too, I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
We mentiontrue as, being an identifier that is not defined as a macro, it should convert to a0 before we turn the preprocessor tokens into tokens in order to evaluate the#if predicate --- we arrange that the only tokens that convert are literals. I think the first note covers that, and the alternative tokens note covers a different matter as alternative tokens are never identifiers. Maybe I am too focused on identifiers as a preprocessing-token that is being converted though?
jensmaurerNov 14, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I was trying to say that your new "note" can go entirely, because "true" is a keyword and is mentioned in the (revised) "identifiers except..." phrasing. That wouldn't be necessary if "true" weren't considered a (preprocessor-level) identifier at that point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I am happy to remove the note --- should I do so now, or wait for more feedback in case others prefer to add the note? I agree that my preference would be to remove the note as I doubt folks would be genuinely confused.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
For comparison, C23 says
... all remaining identifiers other than true (including those lexically identical to keywords such as false) are replaced with the pp-number 0, true is replaced with pp-number 1, and then each preprocessing token is converted into a token.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Of course,true andfalse are essentially integer literals in C, but are boolean literals in C++. By preserving the spelling of the token, we preserve the type in the expression. I do not know how significant that change might be, but if we were to synchronize wording with C it would definitely become a CWG issue due to that type change.
jensmaurerNov 14, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I'm wondering how you would observe the type change at the preprocessor#if level.
That said, the more important part for this pull request is the parenthetical "(including those lexically identical to keywords)" which re-emphasizes that phase 4 "identifiers" can be spelled like phase 7 keywords. That's another option, instead of the note.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
If the note is kept, please leave it at "Keywords are identifiers during preprocessing and are not valid macro names."
d43a454 to1df1072Compare
hubert-reinterpretcast left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I believe that the exception should be delimited by commas of a parenthetical nature.
| \grammarterm{has-attribute-expression}s | ||
| have been performed, | ||
| all remaining identifiersandkeywords, | ||
| all remaining identifiers(including those lexically identical tokeywords) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
| all remaining identifiers (including those lexically identical to keywords) | |
| all remaining identifiers (including those lexically identical to keywords), |
| \tcode{true} | ||
| and | ||
| \tcode{false}, | ||
| \tcode{false} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
| \tcode{false} | |
| \tcode{false}, |
jensmaurer commentedNov 17, 2025
I think I like the overall outcome here. |
Uh oh!
There was an error while loading.Please reload this page.
Move seemingly normative reference to keywords in #if expressions into a note.