3 ms·

TypeScript’s goal isn’t to be sound. Its goal is to be a balance between type-safety and effort. Full type safety would require a lot of runtime checks inject

TypeScript’s goal isn’t to be sound. Its goal is to be a balance between type-safety and effort. Full type safety would require a lot of runtime checks injected into the final JavaScript, which TypeScript intentionally avoids. JavaScript will never be fully type-safe without fundamental changes, which will probably never happen.

yawaramin 7y ago
I understand that, which is why I said 'Which TypeScript is [unsound], by choice'. Disagree that full type safety would require a lot of runtime checks. That's not the experience I've had in ReasonML.
- afiori 7y ago
  ReasonML is exactly the kind of backwards incompatible change that would be necessary. You cannot mix reasonML and JavaScript freely together.
nawitus 7y ago
"Full type safety would require a lot of runtime checks injected into the final JavaScript" Why would this be the case?
- nitram1 7y ago
  Array access is a good example. Many type-safe languages throw an exception if you attempt to access an element in an array that is out of bounds but javascript just returns undefined. Typescript ignores the fact that accessing an arbitrary element of an array could return undefined. If it did not ignore this fact then it would force you to deal with the potential undefined value retrieved from any array access (i.e you'd need to write a runtime check)
  - wwwigham 7y ago
    Index unsafety w.r.t. bounds and `undefined` is something TS would like to fix; but it's not ergonomic to fix until there are, something like automatic refinement range types applied to array length fields. Without it, TS'd get in the way, demanding `undefined` checks it almost definitely didn't need. Those range types and their complexity are, ultimately, what currently block TS from making these indexed accesses safer.
  - the_gipsy 7y ago
    Some languages do force you to check any time you access an element. If the rest of the language is in line with this, then it's actually amazing. Option/Maybe types help here, pattern matching lists also let's you make sure you handle all cases. In some instances it makes sense to use a special NonEmptyList type that guarantees there is always at least one element, so you don't need to check.
crimsonalucard 7y ago
This is absolutely false all type checking in basically every typed language happens precompile time. There is no trade-off here. You completely don't understand.
- catblast 7y ago
  There's a thing called dynamic type checking. It's literally all type checking done at runtime. Even for mostly static typed languages you may want to lookup what a downcast is, it's not obscure.
  - crimsonalucard 7y ago
    I'm not talking about type checking with your run time code. Obviously this is exists. My mistake with the wording. I am referring to the topic the poster is talking about, that is, type checking with type script and the precompile type checker of almost all statically typed languages. The precompile type checks do not need run time code. These are separate things executed at separate times AND really you can get by with 100% static.

yawaramin 7y ago

I understand that, which is why I said 'Which TypeScript is [unsound], by choice'. Disagree that full type safety would require a lot of runtime checks. That's not the experience I've had in ReasonML.

afiori 7y ago
ReasonML is exactly the kind of backwards incompatible change that would be necessary. You cannot mix reasonML and JavaScript freely together.

nawitus 7y ago

"Full type safety would require a lot of runtime checks injected into the final JavaScript" Why would this be the case?

nitram1 7y ago
Array access is a good example. Many type-safe languages throw an exception if you attempt to access an element in an array that is out of bounds but javascript just returns undefined. Typescript ignores the fact that accessing an arbitrary element of an array could return undefined. If it did not ignore this fact then it would force you to deal with the potential undefined value retrieved from any array access (i.e you'd need to write a runtime check)
- wwwigham 7y ago
  Index unsafety w.r.t. bounds and `undefined` is something TS would like to fix; but it's not ergonomic to fix until there are, something like automatic refinement range types applied to array length fields. Without it, TS'd get in the way, demanding `undefined` checks it almost definitely didn't need. Those range types and their complexity are, ultimately, what currently block TS from making these indexed accesses safer.
- the_gipsy 7y ago
  Some languages do force you to check any time you access an element. If the rest of the language is in line with this, then it's actually amazing. Option/Maybe types help here, pattern matching lists also let's you make sure you handle all cases. In some instances it makes sense to use a special NonEmptyList type that guarantees there is always at least one element, so you don't need to check.

crimsonalucard 7y ago

This is absolutely false all type checking in basically every typed language happens precompile time. There is no trade-off here. You completely don't understand.

catblast 7y ago
There's a thing called dynamic type checking. It's literally all type checking done at runtime. Even for mostly static typed languages you may want to lookup what a downcast is, it's not obscure.
- crimsonalucard 7y ago
  I'm not talking about type checking with your run time code. Obviously this is exists. My mistake with the wording. I am referring to the topic the poster is talking about, that is, type checking with type script and the precompile type checker of almost all statically typed languages. The precompile type checks do not need run time code. These are separate things executed at separate times AND really you can get by with 100% static.