News for hackers. Stuff that matters.
Re:Future of TypeScript on ESLint by tazard on Friday January 18, 2019 @06:28PM (#18944112)
Technically typescript is a strict superset of JS, but yes
Re:Future of TypeScript on ESLint by lhorie on Friday January 18, 2019 @07:39PM (#18944467)
Technically technically, it turns out that no it's not. I recently realized that `a<b>(x)`, `a<b,c>(x)` and variations mean something completely different in TS than they do in JS.
Re:Future of TypeScript on ESLint by chrismorgan on Saturday January 19, 2019 @04:33AM (#18946168)
And that’s exactly why Rust has the turbofish (a :: before the <), to resolve that syntactic ambiguity. TypeScript could have resolved it by requiring a . before the <, but it didn’t, and so you can devise contrived cases like this where it differs from JavaScript.
Re:Future of TypeScript on ESLint by spraak on Friday January 18, 2019 @11:32PM (#18945346)
Is that denoting generics? Can you give an example?
Re:Future of TypeScript on ESLint by alangpierce on Friday January 18, 2019 @11:58PM (#18945416)
Yeah, it's the syntax when calling a generic function, e.g. `Array.of<number | null>(1, 2, null);` has return type `Array<number | null>`. You usually don't need to specify the type since TypeScript can figure it out, but sometime's it's necessary to specify it explicitly.

TypeScript compiles `a<b>(x)` to `a(x)`, which is a function call, but when run as plain JS, `a<b>(x)` is a less-than and greater-than comparison between a, b, and x.

Re:Future of TypeScript on ESLint by tazard on Sunday January 20, 2019 @09:57AM (#18953303)
That's interesting and so obvious now that you mention it. Thanks for the clarification.