3 ms·
> If you go all the way and make it sound with variance annotations Variance annotations aren't quite what would make the language (in strict mode) sound. Spec
by wwwigham 8y ago
> If you go all the way and make it sound with variance annotations
Variance annotations aren't quite what would make the language (in strict mode) sound. Specifically, what makes it unsound is the `any` type (generally) and the lack of enforced variance on methods, non-function properties, and index signatures. It doesn't need annotations to determine variance - type parameter variance can be inferred from where in a type a type parameter is used. It already does so for functions (that's the strict flag's strictFunctionTypes subflag). The real issue is that far, far too many people rely on, eg, unsound array assignments (array aughta be invariant over what it contains but it's often treated covariantly), for it to be reasonable to be a default. However it could always be changed (or added) in the future - that's what the strictness flags are for, ideally; providing ways to ratchet up the safety such that it won't permanently break longtime users of the language.
- bcherny 8y agoTotally agreed. The reason to have variance annotations is the language becomes unusable without them. Thats why so many languages with object subtyping support them.
- evmar 8y agoAs far as I understand it, every sound language eventually has to fall back to runtime checks to maintain soundness in tricky cases. For array covariance I know that Java/Dart eventually use runtime checks on array accesses to verify the types work out. However, it's kind of against the spirit of TypeScript to insert runtime checks. For example because the type system models 'undefined', to model out of bounds array accesses you'd either need to make every array access have type T|undefined or insert bounds checks that throw. (I believe Dart does the latter.)