Our main reasoning was:

"&&" is intuitive but it means that you can have a pattern that is immediately followed by an infix operator. That can be problematic if you ever want to make "&&" a valid pattern infix operator. And, in our case, we ended up doing exactly that, so "&&" would have been ambiguous. If you were to write:

    case foo && true:

"if" is nice because it's already a reserved word and the semantics are pretty obvious. But in Dart, an if statement always has the condition in parentheses. Those are pointless in a pattern since we already have another explicit delimiter separating the guard from the case body:

    case foo if (condition):
    //                     ^

If Dart didn't require parentheses around if conditions, we probably would have used "if" for guard clauses to (like Scala and Rust do).

So we tried "when" and most users and team members seem to like it. Syntax design is a human-centered process so often the right answer is just what feels right to the most people.

[1]: https://github.com/dart-lang/language/blob/master/accepted/f...

Syntax design is weird. Sometimes the only way to tell if I did it right is when no one says anything. People complained when I used "if". No one did after I switched it to "when". <shrug>

The flip side is that it also bugs me when language / library designers make weird choices that don’t seem to have a compelling reason (or at least the compelling reason for the difference doesn’t outweigh the cost of being different).

No win situation ultimately except to figure out who has good language tastes and weight their feedback more, but that’s subjective and something people try to avoid, ignoring that they’ve already done this by virtue of limiting who the experts are working on it in the first place.

Familiarity and intuitive structure in a low context language is very important. A language syntax is for humans to comprehend. If a new syntax is under discussion, it's probably around new functionality (or sugar). Where is "encourages innovation" in the list of reasons to use any specific syntax? I would say, far down on the list.

You mention about the human-centred nature of syntax design... do you have any instinct for why one route vs another felt right to users? Do you feel like you've developed a better instinct for this over time, or is it still hard to predict what will feel natural to users?

That's a good question. It is something I spend a lot of time thinking about when I see how users react to a design. In this case, I don't think I have a good answer as to why "when" seemed to go down easier than "if".

> Do you feel like you've developed a better instinct for this over time, or is it still hard to predict what will feel natural to users?

I'd like to believe so, but "if" was my first pick, so I guess not. :)

I think what our team does have now that really helps is better processes to evaluate a design, talk about it, get feedback from users, and incorporate that feedback into the design. It's all pretty informal, but I think we're iteratively able to get designs users seem to like.

But it's always really hard. There are so many trade-offs and users have different preferences and expectations, so finding the right balance is always difficult. I think that's why it's so endlessly fascinating to me: you can never fully "solve" syntax design.

The “if” one does not suffer from any such problem and reads okay to me. I guess one argument against it could be that since the whole thing is a distinct grammatical construct, why not just introduce a distinct keyword instead of making an existing keyword depending on context? That’s mostly a question of style though (e.g. I don’t know right now if Java already has an habit of reusing keywords like that).

FWIW, though, I don't find it "bizarre". While it's not a boolean expression per Java, at least in my mind it serves the same purpose: "in the case that thing x is of type SomeType and ...some other thing about ((SomeType)x) is true...".

I think it's a tough choice, I'm sure they were probably not wanting to add a new keyword, but at the end of the day "when" is so familiar to anyone who's ever written SQL (which I'm guessing is most Java devs) so seems like a good choice.

But if some construct looks the same, but is not the same, and worse, only "somewhat" the same, you get confusing behavior. At least for newcomers, or even just software engineers who just don't care about language grammar that deeply (which I imagine are not only a lot, but also a lot of the Java target audience specifically).

Case in point, the author I was replying to wondered in a followup whether && would/should still act like a shortcut-and operator would, or not.

There is definitely some subjectivity to it, but personally I much prefer if different constructs look clearly different. Any ambiguity is squashed immediately, and in the case of "when" it's still fully clear how it works. I'm also okay with the "if" variant, because while it reuses a keyword, it's clearly a different "if".

Given this pattern matching syntax change, you'd write:

    switch(obj) {
        case Tuner t when guitar.isInTune() -> ...;
        ...
    }

    if (obj instanceof Tuner t && guitar.isInTune()) {
        ...
    }

And don't even get me started on `static` in C++.

    type when expression -> block

    if expression -> block

https://stackoverflow.com/questions/199918/explaining-patter...

I think the difference is when you start pattern matching on tuples and other types that you cannot do a simple `if ident.isinstanceof(type) ->`.

For example in Elixir you can do:

    def ident(param = {:key => true}):

In the end though, it's syntax sugar (but everything is if you put it that way classes are syntax sugar).

At 3rd preview, they switched to when: https://openjdk.org/jeps/427

In that JEP they state:

> Based upon experience and feedback we propose instead to allow when clauses in switch blocks to specify guards to pattern labels

So I assume people thought && was confusing.

In the case of "if", you're right, the grammar doesn't work, both because the syntax of Java already says that the if condition must be enclosed in parentheses and also because an if block is a statement and you need an expression here.

To make either of those work, you'd have to make the rest of the pattern matching syntax much worse.

https://en.wikipedia.org/wiki/Java_version_history

The non-LTS releases are every 6 months and have support for one year.

LTS releases are every 4th release which falls on odd numbered years in September.

Not exactly, they are supported for 6 months (well, till the next JDK release) at least the builds on jdk.java.net page. Other vendors might provide different support.

Azul for example supports some releases (13 and 15) for 3.5 or 2.5 years (MTS)

And now I’ll get 21 soon? Awesome.

var favoriteTask = obj switch

{

  Developer dev when dev.YearOfBirth == 1980 => $"{dev.FirstName} listens to metal",

  Developer dev => $"{dev.FirstName} writes code",

  Manager _ => "Create meetings",

  _ => "Do what objects do",