Could we change the syntax for when clauses?

[Brian Goetz]

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.

Well, contextual keywords have been a thing for a long time, so to some degree, its already no longer “within reach.”  But I don’t think we should worry too much about a flood; each feature is carefully considered and we try to balance all the competing concerns.

We agree that we should use them with care.  I think where we disagree is the weights we assign in the balancing of the tradeoffs, and specifically, how we balance what is “good for the users” with what is “good for the implementers.”  The purpose of the keywords JEP was (a) to outline the space we are working within today, and (b) expand into a new space which may give us more options.

For example, we could decide to use “double” instead of when:

    case Integer x double x > 0:

But that would be pretty silly, because it makes no sense.  There is limited ability to overload existing keywords and operators within the bounds of maintaining a reasonable language.

The hyphenation gives us a broader range of non-contextual keywords, which increases the chance we’ll find something good.  But this would also be bad:

    case Integer x double-checking-that x > 0:

Because it would be clear that we’re only using `double` because its a keyword, not because it makes sense here.  We have more options, but we still have to use sense and taste to not pick the bad ones.

Moving down the scale, hyphenated contextual keywords (e.g., non-sealed) are probably fine in some contexts (e.g., class declarations) and less fine in others.  (Everything its its own consideration.). And they don’t make anything easier for parser writers anyway.

Second, the hyphen (-) in Java is currently used to denote subtraction (ignore the "non-sealed" keyword for now).

Let’s not ignore non-sealed.  There are two kinds of hyphenated keywords: those that can be true keywords because one or both words is already a keyword and therefore the dash could not be subtraction (e.g., non-final), and those where neither word is a keyword and therefore both could be identifiers (these are contextual hyphenated keywords.). The latter is still harder for parser writers.

Therefore, if we follow the pattern of

IDENTIFIER --> HYPHEN --> KEYWORD

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

Yes, but I think you’re overvaluing the power of this as a generator.  There’s just not that many keywords, and therefore most of the ones that this generator produces are going to be silly like double-checking-when.

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?

The sands of time often resist excavation...

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

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.

In a community of 10M users, we’re not aiming for unanimity, because that’s impossible.  But yes, you can’t please all the people all of the time.  We aim for decisions that, ten years from now, don’t stand out.  (We often struggle with Stroustrup’s rule here too.).

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.

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

This one was discussed at some length and was rejected with prejudice :)

- 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.
- case-if ----- The middle ground between the above 2.
- only-if ----- Since "only-when" was suggested before, maybe this one? It's no longer context-dependent now.

I will admit the last one “isn’t terrible”, though it definitely STANDS OUT (see “Stroustrup’s Rule”) and I suspect the ten-year test will prefer “when” pretty strongly.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221128/e35dad8d/attachment.htm>