3 ms·
Total type soundness is not a goal of Flow. For example, array bounds are not considered. Flow considers this program to have no errors, but TypeScript (with t
by RyanCavanaugh 4y ago
Total type soundness is not a goal of Flow.
For example, array bounds are not considered. Flow considers this program to have no errors, but TypeScript (with the correct option enabled) will:
let m = [1, 2, 3];
console.log(m[4].toFixed());
Also, DefinitelyTyped itself launched before Flow (2012 vs 2015), so the timeline on that point isn't right.
- dimitropoulos 4y ago> Flow tries to be as sound and complete as possible. > https://flow.org/en/docs/lang/types-and-expressions/ https://flow.org/en/docs/lang/types-and-expressions/ That's what I was talking about re: Flow. That's a really insightful comment you make about the "turn of the phrase" between how the two marketed themselves. Super interesting stuff. also, apologies for messing up the timeline on the DT repo. My memory failed me there. Has it been that long?!?
- RyanCavanaugh 4y agoTypeScript tries to be sound too. It wouldn't really make sense to write a type checker if that wasn't your goal. As the person who wrote the "100% soundness is a non-goal" line in the design goals document, that's there to serve the same role as "Flow sometimes has to make a tradeoff" in the Flow docs in terms of clarifying whether or not 100% soundness is a design goal. For both projects, the answer is "no". It's unfortunate that people have, over the years, decided that just being upfront about this fact means that TypeScript has a vastly different prioritization of soundness than Flow. We don't; both checkers use soundness as the default assumption when designing behavior.