[c0nfused]

Its an interesting concept but, The choice of syntax seems bad.

The definition bit looks like a function definition but behaves entirely differently. Why? Why not make it a constructor like everything else? People could look at it and be like "oh a match object" instead of wondering if you overloaded function.

The selectors look like json, only assignable. Again make it obvious.I mean we could even just make it json why not.

[irrational]

I made the same type of arguments about fat arrows but everyone told me to stop whining and I'd get used to it. Years later fat arrows still feel like a bad syntax choice.

[dvlsg]

Really? I quite like them. I did get used to them in C# first, though. What would you have preferred?

[mattbierner]

From a language design perspective, fat arrows make parsing unnecessarily complicated because you cannot distinguish "(a, b, c)" from "(a, b, c) => ..." without looking ahead or backtracking. Certainly not difficult to solve, but this choice makes extending arrow syntax more difficult and the fact that a production called `CoverParenthesizedExpressionAndArrowParameterList` exists in the language grammar is a pretty ugly IMO

[irrational]

I would have preferred a word.

const my_arrow_function = arrow_function(){}

arrow_function my_arrow_function(){}

arrow_function(){}

[warty]

In older C#, that would be delegate:

    delegate(int x){ return 10; }

(But yeah, nowadays that would be:)

    (int x) => 10

[strainer]

And they are ready to overload them here :/