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()…
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 ca…
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?