| There was a lengthy discussion some time ago[0]. Quote: #### Why not "just" make contextual keywords? At first glance, contextual keywords (and their friends, such as
reserved type identifiers) may appear to be a magic wand; they let us
create the illusion of adding new keywords without breaking existing
programs. But the positive track record of contextual keywords hides
a great deal of complexity and distortion. Each grammar position is its own story; contextual keywords that might
be used as modifiers (e.g., `readonly`) have different ambiguity
considerations than those that might be use in code (e.g., a `matches`
expression). The process of selecting a contextual keyword is not a
simple matter of adding it to the grammar; each one requires an
analysis of potential current and future interactions. Similarly,
each token we try to repurpose may have its own special
considerations; for example, we could justify the use of `var` as a
reserved type name because because the naming conventions are so
broadly adhered to. Finally, the use of contextual keywords in
certain syntactic positions can create additional considerations for
extending the syntax later. Contextual keywords create complexity for specifications, compilers,
and IDEs. With one or two special cases, we can often deal well
enough, but if special cases were to become more pervasive, this would
likely result in more significant maintenance costs or bug tail. While
it is easy to dismiss this as “not my problem”, in reality, this is
everybody’s problem. IDEs often have to guess whether a use of a
contextual keyword is a keyword or identifier, and it may not have
enough information to make a good guess until it’s seen more input.
This results in worse user highlighting, auto-completion, and
refactoring abilities — or worse. These problems quickly become
everyone's problems. So, while contextual keywords are one of the tools in our toolbox,
they should also be used sparingly. [0]. https://mail.openjdk.java.net/pipermail/amber-spec-experts/2... |