Hacker News Reader

Comment by phpnode | Hacker News Reader

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?

View on HN

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.

There is no type annotation proposal.

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).

https://ramdajs.com/docs/#partial

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.

Reply on news.ycombinator.com