6 ms·

This is exciting, can't wait for the LTS release next year... that said, I don't much care for the "case SomeType t when ..." pattern matching syntax, I don't s

This is exciting, can't wait for the LTS release next year... that said, I don't much care for the "case SomeType t when ..." pattern matching syntax, I don't see the benefit of introducing a new keyword over using "if"... or even just "&&". To pinch the example used in[1]: case Tuner t && guitar.isInTune() -> ...; and case Tuner t if guitar.isInTune() -> ...; both seem as clear as case Tuner t when guitar.isInTune() -> ...; ...am I misunderstanding the reasoning here? Is it being introduced to keep the grammar definition simpler? 1: https://foojay.io/today/its-java-20-release-day-heres-whats-new/ https://foojay.io/today/its-java-20-release-day-heres-whats-...

mason55 4y ago
In the case of &&, the left hand side of the expression (Tuner t) isn't a boolean expression. 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.
- anyfoo 4y ago
  The “&&” one is super confusing indeed, but the “if” one is just a question of style. It would be possible to reuse the “if” keyword for different grammar. python does it for its trinary operator, where there is an expression instead of a statement after “then” (e.g. “foo = if bar then 1 else 2”), but if Java does not have the same habit of reusing keywords already (not sure), it might not want to start now for consistency.
  - lmm 4y ago
    Java has two gramatically different forms of "try" in a similar fashion (one with parantheses and one without), I don't think this would be any worse than that.
    - anyfoo 4y ago
      Agreed. I guess "when" just reads a little bit better (english-wise), then.
papruapap 4y ago
they want it to be as ugly as cpp
- dang 4y ago
  Maybe so, but please don't post unsubstantive and/or flamebait comments to Hacker News. We're trying for something different here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
bcrosby95 4y ago
In 2nd preview, they used &&: https://openjdk.org/jeps/420 https://openjdk.org/jeps/420 At 3rd preview, they switched to when: https://openjdk.org/jeps/427 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.
- deleted 4y ago
  [deleted]
anyfoo 4y ago
The “&&” one is bizarre, it makes it look like the whole thing is a Boolean expression, which it absolutely is not. That gets even weirder because the part right of it actually is a Boolean expression, so on top of very confusing reading you now make it look like there are strange interactions with operator precedence. Using && is one of the worst choices. 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).
- mikepurvis 4y ago
  I'm not a Java user, but I really don't love the overloading of `if` in Python (statement, ternary, comprehensions), so introducing a new keyword here seems pretty reasonable to me. And don't even get me started on `static` in C++.
  - pajko 4y ago
    OK, no static then, but what about if constexpr (...) ? :D
    - planede 4y ago
      Also `if consteval {...}` in C++23. But really "if" still semantically means the same thing in all of these. Unlike "static", which is all over the place.
    - rerdavies 4y ago
      And then there's "static constexpr" (which is only used in places where non-static constexprs are illegal). An overloaded keyword that's become so overloaded, it's even used in places where it's completely unnecessary! :-P
- garblegarble 4y ago
  The "&&" approach is how you express that same logic in an if statement in Java today. Given this pattern matching syntax change, you'd write: switch(obj) { case Tuner t when guitar.isInTune() -> ...; ... } For a switch, but for an if statement it's written as: if (obj instanceof Tuner t && guitar.isInTune()) { ... } Edit: I do wonder, actually, if avoiding "&&" is to allow the "when" case execution to be reordered (e.g. to allow JIT to extract common "when" conditions prior to the switch expression), which would be wrong to do given the short-circuiting rule implications of "&&"
pron 4y ago
This year. Six months from today.
- MBCook 4y ago
  Oh really? Sweet. It’s only relatively recently I’ve been able to use Java 17 everywhere (there were straggler codebases). And now I’ll get 21 soon? Awesome.
- shagie 4y ago
  (just on the following up on this) https://en.wikipedia.org/wiki/Java_version_history 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.
  - krzyk 4y ago
    > The non-LTS releases are every 6 months and have support for one year. 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)
lifewallet_dev 4y ago
I think the only reason is that they're very different, if you define them: type when expression -> block if expression -> block For parsing works better, for programmers is better since they don't confuse both concepts, and in general pattern matching isn't the same as a if condition or a switch. https://stackoverflow.com/questions/199918/explaining-pattern-matching-vs-switch 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}): This will only match when the param type is not only `map`, but also contains a key named `:key` and its value is `true`. In the end though, it's syntax sugar (but everything is if you put it that way classes are syntax sugar).
munificent 4y ago
I work on Dart which is also adding pattern matching [1]. When we designed the syntax for guards, we also considered exactly these three choices before ultimately landing on "when" too. 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: Then it could be parsed as either a pattern that matches when the value is equal to the constant "foo" and is equal to the constant "true". Or it could be parsed as a pattern that matches when the value is equal to the constant "foo" followed by a pointless guard that always succeeds. "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): // ^ We could say that the if condition in a guard doesn't need parentheses but if conditions elsewhere do. But that's likely just an annoying footgun where users will write them unnecessarily (but harmelessly at least) in guards and forget them in if statements and get compile errors. 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/future-releases/0546-patterns/feature-specification.md https://github.com/dart-lang/language/blob/master/accepted/f...
- Pet_Ant 4y ago
  Gotta say I'd've taken the if with parentheses myself. Feels like it's reusing something familiar even if they are extraneous at times.
  - munificent 4y ago
    That was my initial pitch too. But after months, almost no one seemed to have warmed up to it. When we changed it to "when", just about everyone seemed to like it better. 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>
DeathArrow 4y ago
Maybe they got inspired by C#? 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", };

mason55 4y ago

In the case of &&, the left hand side of the expression (Tuner t) isn't a boolean expression. 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.

anyfoo 4y ago
The “&&” one is super confusing indeed, but the “if” one is just a question of style. It would be possible to reuse the “if” keyword for different grammar. python does it for its trinary operator, where there is an expression instead of a statement after “then” (e.g. “foo = if bar then 1 else 2”), but if Java does not have the same habit of reusing keywords already (not sure), it might not want to start now for consistency.
- lmm 4y ago
  Java has two gramatically different forms of "try" in a similar fashion (one with parantheses and one without), I don't think this would be any worse than that.
  - anyfoo 4y ago
    Agreed. I guess "when" just reads a little bit better (english-wise), then.

papruapap 4y ago

they want it to be as ugly as cpp

dang 4y ago
Maybe so, but please don't post unsubstantive and/or flamebait comments to Hacker News. We're trying for something different here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.

bcrosby95 4y ago

In 2nd preview, they used &&: https://openjdk.org/jeps/420 https://openjdk.org/jeps/420 At 3rd preview, they switched to when: https://openjdk.org/jeps/427 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.

deleted 4y ago
[deleted]

anyfoo 4y ago

The “&&” one is bizarre, it makes it look like the whole thing is a Boolean expression, which it absolutely is not. That gets even weirder because the part right of it actually is a Boolean expression, so on top of very confusing reading you now make it look like there are strange interactions with operator precedence. Using && is one of the worst choices. 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).

mikepurvis 4y ago
I'm not a Java user, but I really don't love the overloading of `if` in Python (statement, ternary, comprehensions), so introducing a new keyword here seems pretty reasonable to me. And don't even get me started on `static` in C++.
- pajko 4y ago
  OK, no static then, but what about if constexpr (...) ? :D
  - planede 4y ago
    Also `if consteval {...}` in C++23. But really "if" still semantically means the same thing in all of these. Unlike "static", which is all over the place.
  - rerdavies 4y ago
    And then there's "static constexpr" (which is only used in places where non-static constexprs are illegal). An overloaded keyword that's become so overloaded, it's even used in places where it's completely unnecessary! :-P
garblegarble 4y ago
The "&&" approach is how you express that same logic in an if statement in Java today. Given this pattern matching syntax change, you'd write: switch(obj) { case Tuner t when guitar.isInTune() -> ...; ... } For a switch, but for an if statement it's written as: if (obj instanceof Tuner t && guitar.isInTune()) { ... } Edit: I do wonder, actually, if avoiding "&&" is to allow the "when" case execution to be reordered (e.g. to allow JIT to extract common "when" conditions prior to the switch expression), which would be wrong to do given the short-circuiting rule implications of "&&"

pron 4y ago

This year. Six months from today.

MBCook 4y ago
Oh really? Sweet. It’s only relatively recently I’ve been able to use Java 17 everywhere (there were straggler codebases). And now I’ll get 21 soon? Awesome.
shagie 4y ago
(just on the following up on this) https://en.wikipedia.org/wiki/Java_version_history 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.
- krzyk 4y ago
  > The non-LTS releases are every 6 months and have support for one year. 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)

lifewallet_dev 4y ago

I think the only reason is that they're very different, if you define them: type when expression -> block if expression -> block For parsing works better, for programmers is better since they don't confuse both concepts, and in general pattern matching isn't the same as a if condition or a switch. https://stackoverflow.com/questions/199918/explaining-pattern-matching-vs-switch 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}): This will only match when the param type is not only `map`, but also contains a key named `:key` and its value is `true`. In the end though, it's syntax sugar (but everything is if you put it that way classes are syntax sugar).

munificent 4y ago

I work on Dart which is also adding pattern matching [1]. When we designed the syntax for guards, we also considered exactly these three choices before ultimately landing on "when" too. 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: Then it could be parsed as either a pattern that matches when the value is equal to the constant "foo" and is equal to the constant "true". Or it could be parsed as a pattern that matches when the value is equal to the constant "foo" followed by a pointless guard that always succeeds. "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): // ^ We could say that the if condition in a guard doesn't need parentheses but if conditions elsewhere do. But that's likely just an annoying footgun where users will write them unnecessarily (but harmelessly at least) in guards and forget them in if statements and get compile errors. 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/future-releases/0546-patterns/feature-specification.md https://github.com/dart-lang/language/blob/master/accepted/f...

Pet_Ant 4y ago
Gotta say I'd've taken the if with parentheses myself. Feels like it's reusing something familiar even if they are extraneous at times.
- munificent 4y ago
  That was my initial pitch too. But after months, almost no one seemed to have warmed up to it. When we changed it to "when", just about everyone seemed to like it better. 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>

DeathArrow 4y ago

Maybe they got inspired by C#? 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", };