3 ms·
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
by c0nfused 8y ago
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 8y agoI 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.
- strainer 8y agoAnd they are ready to overload them here :/
- dvlsg 8y agoReally? I quite like them. I did get used to them in C# first, though. What would you have preferred?
- irrational 8y agoI would have preferred a word. const my_arrow_function = arrow_function(){} arrow_function my_arrow_function(){} arrow_function(){}
- warty 8y agoIn older C#, that would be delegate: delegate(int x){ return 10; } (But yeah, nowadays that would be:) (int x) => 10
- mattbierner 8y agoFrom 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