Skip to content

[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.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+6 −2
Open

[cpp.cond] Keywords are not identifiers while preprocessing #8518

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions source/preprocessor.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -553,15 +553,19 @@
\grammarterm{has-embed-expression}s, and
\grammarterm{has-attribute-expression}s
have been performed,
all remaining identifiers and keywords,
all remaining identifiers
except for
\tcode{true}
and
\tcode{false},
\tcode{false}
are replaced with the \grammarterm{pp-number}
\tcode{0},
and then each preprocessing token is converted into a token.
\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}
Comment on lines 564 to +567
Copy link
Member

@jensmaurer jensmaurer Nov 14, 2025

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.

Copy link
Contributor Author

@AlisdairM AlisdairM Nov 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We mention true as, being an identifier that is not defined as a macro, it should convert to a 0 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?

Copy link
Member

@jensmaurer jensmaurer Nov 14, 2025 •
edited
Loading

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.

Copy link
Contributor Author

@AlisdairM AlisdairM Nov 14, 2025

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.

Copy link
Member

@jensmaurer jensmaurer Nov 14, 2025

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.

Copy link
Contributor Author

@AlisdairM AlisdairM Nov 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course, true and false 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.

Copy link
Member

@jensmaurer jensmaurer Nov 14, 2025 •
edited
Loading

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.

Copy link
Contributor

@hubert-reinterpretcast hubert-reinterpretcast Nov 15, 2025

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."

\begin{note}
An alternative
token\iref{lex.digraph} is not an identifier,
even when its spelling consists entirely of letters and underscores.
Expand Down