Greg,
It sounds like you are proposing that an exception should be made to
allow keywords here. I would oppose such a thing.
You seem to be focusing on the fact that the resulting formed identifiers
would not be keywords. This is irrelevant. The reason for reserving
keywords is not to prevent the formation of identifiers that happen to
match keywords. Note that you can already form such identifiers using
escapes. The reason for reserving keywords is to avoid the need for
tools (and human readers) to use complex context information to determine
whether an apparent keyword in the source text is actually a keyword.
For that, what matters is the tokens in the source text, not the names
finally formed.
If we wanted to make it illegal to form an identifier that matches a
keyword, we could do that. I don't think it is called for, given that
you can already form such identifiers using escapes. And escapes even
provide a mechanism for accessing an identifier created with an enum
range. It could be restricted if it provided some useful protection for
users, though I don't see that it does.
Allowing keywords in the source text is another matter. Nor do I think
that things allowed for macro text are a precedent for other source text.
Text preprocessing such as macro expansion is generally done somewhat
separately from the lexing and parsing steps that follow it. This enum
syntax is not something I would expect to be handled by any type of
preprocessing, but by the normal lexing and parsing steps.
Steven Sharp
sharp@cadence.com
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Mar 22 14:16:34 2010
This archive was generated by hypermail 2.1.8 : Mon Mar 22 2010 - 14:16:41 PDT