<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
As you point out, this isn’t really about `when`; if we did as you say for `when`, you’d write exactly the same mail the next time we consider a contextual keyword.  What you’re really asking is: “can we please stop using contextual keywords.”  (You’ve clearly
 read  <a href="https://bugs.openjdk.org/browse/JDK-8223002" class="">https://bugs.openjdk.org/browse/JDK-8223002</a> (“Keyword Management for the Java Language”), but others reading this exchange may not have, any may benefit from going back and reading it.). 
<div class=""><br class="">
</div>
<div class="">Whenever we consider new language syntax, we are called upon to make tradeoffs between many considerations, including: </div>
<div class=""><br class="">
</div>
<div class=""> - Compatibility with the existing language.  (We could declare `when` to be a real keyword, but that would break any code that uses it as an identifier.)</div>
<div class=""> - Naturalness of the improved language.  (We could pick a new keyword that is unlikely to conflict with existing code, like `guardedByTheFollowingBooleanCondition`, but writing code in this language would be unpleasant.)</div>
<div class=""> - Complexity for tools and specification.  (We bear most of this cost, but others in the ecosystem bear some as well.)</div>
<div class=""> - Progress vs stagnation.  (We could choose not to do guards at all.)</div>
<div class=""><br class="">
</div>
<div class="">The “keyword management” JEP explicitly acknowledges the challenges with contextual keywords: </div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<p style="margin: 10px 0px 0px; padding: 0px; color: rgb(23, 43, 77); font-family: "DejaVu Sans", sans-serif; font-size: 14px; font-variant-ligatures: normal; orphans: 2; widows: 2; background-color: rgb(255, 255, 255); text-decoration-thickness: initial;" class="">
<strong class="">Cautiously consider contextual keywords</strong></p>
<p style="margin: 10px 0px 0px; padding: 0px; color: rgb(23, 43, 77); font-family: "DejaVu Sans", sans-serif; font-size: 14px; font-variant-ligatures: normal; orphans: 2; widows: 2; background-color: rgb(255, 255, 255); text-decoration-thickness: initial;" class="">
At first glance, unitary contextual keywords (and their friends, reserved type names) appear to be a magic wand: they let language designers create the illusion of new keywords without breaking existing programs. However, the positive track record of unitary
 contextual keywords hides a great deal of complexity and distortion.</p>
<p style="margin: 10px 0px 0px; padding: 0px; color: rgb(23, 43, 77); font-family: "DejaVu Sans", sans-serif; font-size: 14px; font-variant-ligatures: normal; orphans: 2; widows: 2; background-color: rgb(255, 255, 255); text-decoration-thickness: initial;" class="">
The process of introducing a unitary contextual keyword is not a simple matter of choosing a word and adding it to the grammar; each one requires an analysis of potential current and future interactions. Each grammar position is its own story: contextual keywords
 that might be used as modifiers (e.g., <code class="prettyprint" style="font-family: SFMono-Medium, "SF Mono", "Segoe UI Mono", "Roboto Mono", "Ubuntu Mono", Menlo, Courier, monospace;">readonly</code>) have different ambiguity considerations than those that
 might be used in code (e.g., a <code class="prettyprint" style="font-family: SFMono-Medium, "SF Mono", "Segoe UI Mono", "Roboto Mono", "Ubuntu Mono", Menlo, Courier, monospace;">match</code> expression). While a small number of special situations can be managed
 in a specification or a compiler, the more heavily that unitary contextual keywords are used, the more likely there would be more significant maintenance costs and longer bug tails.</p>
<p style="margin: 10px 0px 0px; padding: 0px; color: rgb(23, 43, 77); font-family: "DejaVu Sans", sans-serif; font-size: 14px; font-variant-ligatures: normal; orphans: 2; widows: 2; background-color: rgb(255, 255, 255); text-decoration-thickness: initial;" class="">
Beyond specifications and compilers, unitary contextual keywords distort the language for IDEs. IDEs often have to guess whether an identifier is meant to be an identifier or a unitary contextual keyword, and it may not have enough information to make a good
 guess until it has seen more input. While this is easy to dismiss as “not my problem”, in reality, it results in worse code highlighting, auto-completion, and refactoring abilities for everybody. (IDEs have the same trouble with hyphenated contextual keywords
 too.)</p>
<p style="margin: 10px 0px 0px; padding: 0px; color: rgb(23, 43, 77); font-family: "DejaVu Sans", sans-serif; font-size: 14px; font-variant-ligatures: normal; orphans: 2; widows: 2; background-color: rgb(255, 255, 255); text-decoration-thickness: initial;" class="">
Finally, each identifier that is a candidate for dual-purposing as a unitary contextual keyword may have its own special considerations. For example, the use of <code class="prettyprint" style="font-family: SFMono-Medium, "SF Mono", "Segoe UI Mono", "Roboto Mono", "Ubuntu Mono", Menlo, Courier, monospace;">var</code> as
 a restricted identifier is justified only because the <a href="https://docs.oracle.com/javase/specs/jls/se12/html/jls-6.html#jls-6.1" class="external-link" target="_blank" rel="nofollow noopener" style="color: rgb(0, 82, 204); text-decoration: var(--aui-link-decoration); cursor: pointer;">naming
 conventions for type names</a> are so broadly adhered to. Using a hyphenated contextual keyword rather than a unitary contextual keyword can sidestep these considerations, since the hyphenated phrase has never been used as an identifier, though the ambiguity
 issue remains.</p>
<p style="margin: 10px 0px 0px; padding: 0px; color: rgb(23, 43, 77); font-family: "DejaVu Sans", sans-serif; font-size: 14px; font-variant-ligatures: normal; orphans: 2; widows: 2; background-color: rgb(255, 255, 255); text-decoration-thickness: initial;" class="">
In summary, unitary contextual keywords are a tool in the language design toolbox, but they should be used with care.</p>
</blockquote>
</div>
<div class=""><br class="">
</div>
<div class="">Despite these challenges, usability remains paramount.  (Remember too that many proposed hyphenated keywords are also contextual, unless one or both parts are existing keywords.). </div>
<div class=""><br class="">
</div>
<div class="">If there were a better candidate that didn’t have these challenges, we would have likely preferred that.  We did try &&, which avoided this bullet, but which ultimately fell afoul of usabilty concerns.  No credible alternatives were proposed that
 avoided the problem; even most hyphenated options (e.g., `only-when`) were still contextual, and users would surely have complained “why do I have to type this long thing.”  </div>
<div class=""><br class="">
</div>
<div class="">Did you have a better candidate in mind?  </div>
<div class=""><br class="">
</div>
<div class="">
<div class="">
<div class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Nov 27, 2022, at 7:07 PM, David Alayachew <<a href="mailto:davidalayachew@gmail.com" class="">davidalayachew@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div style="font-family:monospace" class="gmail_default">Hello Amber Dev Team,<br class="">
<br class="">
In regards to when clauses, is it possible that we could use a keyword for when clauses that is not the "context-dependent" style keyword? And when I say "context-dependent", I mean that the word "when" is a valid identifier, but we are using context to be
 able to figure out where it should be treated as a keyword vs. an identifier. <br class="">
<br class="">
The reason I am requesting this is because everytime a context-dependent keyword is added to Java, all the developers who make language/grammar parsing tools for the Java language have to rewrite/uproot nontrivial parts of their code to deal with several finnicky
 edge cases. It bogs down so much of the parsing logic that a lot of potential optimizations or cleaner solutions go out of the window. This leads to buggy code and/or features not being supported. Much of that could be avoided by choosing a keyword that is
 not context-dependent. I understand that there does exist a grammar for the language, but because<br class="">
<br class="">
Personally, I'd like it if as a language, Java never used this tactic for any new language feature. But for now, I am only requesting that we use a non-context-dependent phrase to signify when clauses. One suggestion would be to use the "Hyphenated classic
 keyword" strategy discussed in this JEP Draft (<a href="https://openjdk.org/jeps/8223002" class="">https://openjdk.org/jeps/8223002</a>).<br class="">
<br class="">
Thank you for your time and patience!<br class="">
David Alayachew</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</body>
</html>