6 ms·

Pattern matching in switch statements (calling them match statements would then be more fitting), a nice way to deal with nulls, and proper sum types (aka tagge

by cies 7y ago

Pattern matching in switch statements (calling them match statements would then be more fitting), a nice way to deal with nulls, and proper sum types (aka tagged unions, like enums in Rust) and Java would be pretty up-to-date.

sleavey 7y ago
Oooh that's a good idea. Does that already exist in other languages? I've not seen it before.
- nestorD 7y ago
  Ocaml, F#, Rust, Kotlin (I believe), Haskell, etc It is a common feature in languages derives from the ML family[0]. [0]: https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language)
  - kod 7y ago
    Kotlin doesn't have real pattern matching.
    - lllr_finger 7y ago
      It doesn't, but at least 'when' statements will be exhaustive when working with sealed classes - which is a breath of fresh air if you enjoy working with sum types and pattern matching.
      - kod 7y ago
        when expressions will be exhaustive, when statements will not. Needless distinctions like that make the fresh air a little less fresh...
- walkingolof 7y ago
  Scala has had this for a long long time: https://docs.scala-lang.org/tour/pattern-matching.html https://docs.scala-lang.org/tour/pattern-matching.html
- deleted 7y ago
  [deleted]
- johnlinvc 7y ago
  Swift also have them.
AstralStorm 7y ago
You still get the ancient and quirky generic programming, barely a support.
MaxBarraclough 7y ago
I'm still not sure why imperative/OOP language have been so resistant to adding pattern-matching of the sort seen in Haskell and OCaml. There are plenty of almost entirely pointless features that get implemented in major languages, like 'events' in C#. They add almost no value to the programmer. Pattern-matching would be really useful for avoiding rats' nests of control-flow, but until recently no major imperative language even seemed to consider adding them. The extremely obscure Felix programming language has had pattern matching for years. [0] As nestorD says, Rust has them now, as does Kotlin. About time. [0] http://felix-lang.github.io/felix/ http://felix-lang.github.io/felix/
- macintux 7y ago
  Erlang is where I first encountered pattern matching, and it's so integral to the language it simply would cease to exist without it. I was pleasantly surprised when I discovered Python 2 would pattern match tuples in function parameters...and then very disappointed when I discovered a few weeks later that Python 3 had removed even that minimal amount of syntactic sugar.
- AlphaSite 7y ago
  Its coming to java: https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html https://cr.openjdk.java.net/~briangoetz/amber/pattern-match....
  - cies 7y ago
    There's also some draft for the proper sum types (aka tagged unions). But we need 'm confirmed! Cannot get my code to use it and then they do not get in and I have to un-cleanup the code base.
- skybrian 7y ago
  I'm curious if there is an elegant way to deal with backward compatibility when adding another case to a widely used sum type? Is it just a matter of fixing all the compile errors immediately?

by cies 7y ago

sleavey 7y ago

Oooh that's a good idea. Does that already exist in other languages? I've not seen it before.

nestorD 7y ago
Ocaml, F#, Rust, Kotlin (I believe), Haskell, etc It is a common feature in languages derives from the ML family[0]. [0]: https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language)
- kod 7y ago
  Kotlin doesn't have real pattern matching.
  - lllr_finger 7y ago
    It doesn't, but at least 'when' statements will be exhaustive when working with sealed classes - which is a breath of fresh air if you enjoy working with sum types and pattern matching.
    - kod 7y ago
      when expressions will be exhaustive, when statements will not. Needless distinctions like that make the fresh air a little less fresh...
walkingolof 7y ago
Scala has had this for a long long time: https://docs.scala-lang.org/tour/pattern-matching.html https://docs.scala-lang.org/tour/pattern-matching.html
deleted 7y ago
[deleted]
johnlinvc 7y ago
Swift also have them.

AstralStorm 7y ago

You still get the ancient and quirky generic programming, barely a support.

MaxBarraclough 7y ago

I'm still not sure why imperative/OOP language have been so resistant to adding pattern-matching of the sort seen in Haskell and OCaml. There are plenty of almost entirely pointless features that get implemented in major languages, like 'events' in C#. They add almost no value to the programmer. Pattern-matching would be really useful for avoiding rats' nests of control-flow, but until recently no major imperative language even seemed to consider adding them. The extremely obscure Felix programming language has had pattern matching for years. [0] As nestorD says, Rust has them now, as does Kotlin. About time. [0] http://felix-lang.github.io/felix/ http://felix-lang.github.io/felix/

macintux 7y ago
Erlang is where I first encountered pattern matching, and it's so integral to the language it simply would cease to exist without it. I was pleasantly surprised when I discovered Python 2 would pattern match tuples in function parameters...and then very disappointed when I discovered a few weeks later that Python 3 had removed even that minimal amount of syntactic sugar.
AlphaSite 7y ago
Its coming to java: https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html https://cr.openjdk.java.net/~briangoetz/amber/pattern-match....
- cies 7y ago
  There's also some draft for the proper sum types (aka tagged unions). But we need 'm confirmed! Cannot get my code to use it and then they do not get in and I have to un-cleanup the code base.
skybrian 7y ago
I'm curious if there is an elegant way to deal with backward compatibility when adding another case to a widely used sum type? Is it just a matter of fixing all the compile errors immediately?