There's a misunderstanding about stagnating proposals in TC39, that it's because TC39 dislikes a proposal. It's often not the proposal itself but the work of the champion. E.g. not enough research, poor presentation, lack of arguments or it's a topic which requires extra effort.
-
-
Standardizing an unsound type system is pretty unlikely, because then you have to make a lot of aesthetic choices about which unsoundness you're willing to accept. As a TS user, I think unsound types add a lot of value, but poor fit for standards in that form.
-
Type grammer in JS??? Please staahhhhp. Does anything matter anymore? Just because userland did something, and there's a tc39 proposal /w implementation doesn't mean it's a winner. Slow & steady = proven track record. Despite negatives. Fast = political fights & frayed goals.pic.twitter.com/vx7sueA7cx
-
I completely agree. However I don’t think that adding opt-in type grammar is a bad thing, no more so then const and let were
-
We would, to start, need TS and Flow to agree on a complete grammar for the type extensions (so they could be reserved correctly), and then we would have to agree we're willing to reserve it.
-
I don't mean TS and Flow have to agree on the exact syntax, but you can't actually reserve syntax without defining it in the grammar ("the stuff after the colon" doesn't tell you where to stop).
-
someFunc(): T => U { } call(T => U) call((i: T => U) => i) All valid TS, but not trivial to reserve type syntax in those positions (especially with recursive type definitions).
-
Whew. I guess I have nothing to worry about for now if we'll be waiting on agreement between tc39, Flow & TS camps. Don't mind me, I'll show myself out... Back to writing
#ReasonML
pic.twitter.com/oRr6TzwZv4 - End of conversation
New conversation -
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.
