Pattern matching is a really important feature but I strongly dislike that proposal because it feels like it introduces a bunch of single purpose syntax that's going to restrict the ability to evolve the language in future. It feels like it's an addon, not a holistic solution.

I would much, much rather that type annotation syntax gets standardised first, because it is comparatively easy to build pattern matching when that's in place but going the opposite direction is difficult. What is a type if not a pattern?

It seems that only `when` and `->`is the new syntax, no? The arrow seems something that could be replaced with `=>`, but anyway, neither seems to be very restrictive with regards to future syntax. (After all they are only defined in a `case` context, so the can be reused for whatever future purpose outside.)

Plus it's a stage1 proposal, meaning it's far from serious.

Could you link the type annotation proposal, I can't find it.

TypeScript is becoming the de facto type annotations proposal.

Let me know when (type inference of) partial function application and object literals are easy in Typescript and I’ll consider it.

Do you have a specific example of code that's hard to annotate in TypeScript? I've been using it for about a year without major issues (except somewhat slow compile times).

In JS, the pattern is the type. That is the point of duck typing.

> In JS, the pattern is the type.

How do you match against a `Buffer` pattern/type?

In the current proposal,

    case (value) {
        when { constructor: Buffer } ->
            console.log("It's a Buffer!")
    }

that doesn't handle subtying though and doesn't work across realms.

Oh interesting you can match on that!

However I think my point stands that javascript has runtime conceptions of types that go beyond duck typing.

Optional chaining recently reached stage 3, the babel plugin is available and TS is going to adopt it for 3.7.0.

Oh I didnt know about TS being so close to have it, that's great news

EDIT: here is the confirmation TS 3.7.0 got tagged: https://github.com/microsoft/TypeScript/issues/16#issuecomme...

EDIT 2: wow just noticed, that the issue ID is "16" and it has been open since Jul 15, 2014 (I guess: good things take time ... ;) )

This is awesome and hopefully 2020 bound. The only thing I remember from my few months of looking into Groovy was the "elvis operator" and being very jealous of it.

I adore pattern matching when done well, but I'm sorry -- that syntax seems terrible and confusing. The use of `{ }` seems arbitrary. In JS braces are already used for both scope-delimiting and object literal notation; now they're going to have a third job? There has to be a better way.

I understand it's based on destructuring; the syntax still just doesn't work for me.

Ocaml, StandardML, F#, Erlang, and Rust all use that syntax for pattern matching. What other syntax would you propose to test values in a JS object?

Yeah very excited about optional chaning, which few days ago got accepted to stage 3 "candidate", so just one more stage (stage 4 "finished"), I guess and hope it will be ready for ES 2020

Z is an interesting approach.

https://dev.to/kayis/pattern-match-your-javascript-with-z-nf...

Optional chaining is stage 3, and major engines are actively implementing it.

These two and decorators (including function/assignment decorators) are the top 3 on my wishlist.

What's the point of pattern matching? Why not just a switch statement?

Switch pivots off of one value, pattern matching allows you to match on types, destructured values, conditional execution based on the existence (or lack thereof) of those values or types. It's much more flexible then switch (but arguably more complex).

See Scala[1] or Swifts[2]'s implementations.

[1] https://docs.scala-lang.org/tour/pattern-matching.html

[2] https://docs.swift.org/swift-book/ReferenceManual/Patterns.h...

Waiting for Optional Chaining. It's in Stage 3 already.