<div dir="ltr"><div style="font-family:monospace" class="gmail_default">Hello Brian,<br><br>Thank you for your response.<br><br>> As you point out, this isn’t really about `when`<br><br>Guilty as charged.<br><br>I see contextual keywords as a tactic that is useful when there is a phrase that is so expressive/useful that it is worth the costs I mentioned in the original post. There's definitely a time and a place for them. However, I also feel like the budget for that has been mostly exhausted already, and that from here on out, I'd like us to move away from this tactic.<br><br>> if we did as you say for `when`, you’d write exactly<br>> the same mail the next time we consider a contextual<br>> keyword.<br><br>To be clear, I certainly didn't and do not intend to raise this point again without something major changing. I just felt like now was a useful time to bring up this discussion because "when clauses" are in preview.<br><br>Also, I get the feeling that the keyword decision made here will likely set the tempo for keyword choices moving forward. For example, it looks like we'll all be seeing a lot more "switches" in Java's near future. So if "when clauses" are received well, I am pretty certain that people will use them as evidence to support using more contextual keywords in the future. You can imagine my concern. Therefore, I'd like to catch it now while it's still within reach.<br><br>> but others reading this exchange may not have (read <br>> the JEP Draft)<br><br>Thank you for pointing this out. I agree, and I will also provide a brief summary here too.<br><br>In short, this JEP Draft takes advantage of 3 facts and combines them together to create a new way to generate new Java keywords that are NOT context-dependent.<br><br>First, there are "classic keywords" in Java that can NEVER be used as an identifier. Here are a few.<br><br>final<br>int<br>double<br>if<br>case<br><br>Second, the hyphen (-) in Java is currently used to denote subtraction (ignore the "non-sealed" keyword for now).<br><br>Third, you can ONLY perform subtraction upon identifiers, NEVER on "classic keywords".<br><br>Therefore, if you combine these 3 facts, you can use the following strategy to be able to create new keywords. The official name the JEP used is "Hyphenated classic keywords".<br><br>If you make a keyword like <br></div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">"record-class"</div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">"record" is considered a valid identifier, but "class" can NEVER be a valid identifier. <br></div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">Therefore, if we follow the pattern of <br></div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">IDENTIFIER --> HYPHEN --> KEYWORD</div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">you can generate all sorts of keywords that are NOT context-dependent. This allows all the language parser folks to simply look for a "classic keyword", see if it is followed by or following a hyphen, then check for the permitted "Hyphenated classic keywords". <br><br>And to be clear, the JEP Draft also suggests other strategies as well that instead use context-dependent concepts. I am not talking about those, only the paragraph of the JEP Draft titled "Hyphenated classic keywords".<br><br>> Whenever we consider new language syntax, we are <br>> called upon to make tradeoffs between many <br>> considerations<br><br>This was very informative, thank you. I had soft concepts for all of this, but this explanation helped solidify where they apply and how we reason about them. Thank you.<br><br>> (We bear most of this cost, but others in the <br>> ecosystem bear some as well.)<br><br>Thank you for highlighting this. Yes, none of my criticism here is to belittle the scale of work being done. I want to make sure that we take the steps that will cause us all the least amount of pain moving forward.<br><br><br>> Despite these challenges, usability remains paramount.<br>> (Remember too that many proposed hyphenated keywords<br>> are also contextual, unless one or both parts are <br>> existing keywords.). <br><br>Thank you for highlighting this. Yes, I think my suggestion contributes nothing unless we use the "Hyphenated classic keywords" strategy. Otherwise, we end up right back in the same hole with a different shovel.<br><br>> If there were a better candidate that didn’t have these<br>> challenges, we would have likely preferred that. We did<br>> try &&, which avoided this bullet, but which ultimately<br>> fell afoul of usabilty concerns.  <br><br>Good to know. Could you tell me roughly the time when these discussions happened on the mailing lists? I try very hard to research these things before posting, but there's no search bar on the mailing list, and google is rarely much help. Perhaps I need to get better at googling?<br><br>> No credible alternatives were proposed that avoided the<br>> problem; even most hyphenated options (e.g., `only-when`)<br>> were still contextual, and users would surely have<br>> complained “why do I have to type this long thing.”<br><br>I can imagine the Amber team's frustration. To be frank, the fact that it is not 2 characters or less is going to cause some users to complain about length. I struggle to find the motivation to appease them with my suggestions.<br><br>> Did you have a better candidate in mind?</div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">Here are a few. NONE of these suggestions are context-dependent (at least, not in the way I have been describing thus far) since they all use a "classic keyword" as part of the phrase.<br><br>- if ---------- Yes, I am proposing to repurpose the if statement here. The concept that the "when clause" represents has strong similarities to an if statement, so maybe this would allow us to build off of users existing mental models? And it should appease all of the 2 char, code golf enthusiasts as well.<br>- case-guard -- Verbose, but clear. No confusion on what this is or means. If expressiveness/clarity was the only priority, this would likely be the best choice.<br>- case-if ----- The middle ground between the above 2.<br>- only-if ----- Since "only-when" was suggested before, maybe this one? It's no longer context-dependent now.<br><br>There are others to be found as well. I believe the below link has all of the "classic keywords"? We can run through more permutations if none of mine are good.<br><br><a href="https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html">https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html</a> <------ Someone correct me if this list is not exhaustive or if it is out of date.<br><br>Thank you for your time and insight!<br>David Alayachew<br></div><br></div>