he/him 
In TC39 we discussed reserving : after a declarator so implementations could not de-facto standardize incompatible type annotations. We knew this would oblige us to standardize type anno/expr syntax at some point. We didn't figure on Flow using ambiguous expression syntax! @awbjs
-
-
sigh…
2 replies 0 retweets 5 likes -
Replying to @awbjs @BrendanEich and
IIRC, folks working on Flow + folks working on TypeScript asked for that syntax extension prohibition
1 reply 0 retweets 3 likes -
The one on declarator : type-annotation? That's good, but what we see now is the backward-incompatibility of C++-style T<U>(V) parameterized type expression syntax.
1 reply 0 retweets 2 likes -
Replying to @BrendanEich @awbjs and
Yes, I was pointing out the uh... irony? Ya know: Flow wants one thing to prevent possibly ambiguous syntax extensions... then makes an ambiguous syntax extension. We're on the same page. It's a bummer for Flow users
2 replies 0 retweets 6 likes -
The obvious hack is to require some extra punctuator in type expressions, e.g. T.<U>(V). That's what we were thinking of for ES4.
2 replies 1 retweet 7 likes -
Replying to @BrendanEich @rwaldron and
Or to put the type params inside: T(<U> V)
2 replies 0 retweets 2 likes -
Beware JSX!
4 replies 0 retweets 12 likes -
Replying to @BrendanEich @awbjs and
Even worse... In Flow/TS there's already ambiguity with JSX and arrow functions with type parameters. const jsx = <X>() => {}</X>; const arrow = <X>() => {};
3 replies 0 retweets 2 likes -
Don't point tags require / before >? (<X/> in the second line)?
2 replies 0 retweets 1 like
Replying to @BrendanEich @awbjs and
Second line is an arrow function with a type parameter. As a regular function: function foo<bar>() {}
9:53 PM - 10 Jun 2019
0 replies
0 retweets
2 likes
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.