Minor correction: this is really more an issue with the `as` operator. For example these also work:
user as unknown as NotUser
user as never as NotUser
`as` let's you cast to arbitrary super- and sub-types. It prevents you from casting to unrelated types directly (here `NotUser`), but you can always use the trick above:
Either cast to the top-type (unknown/any) or bottom-type (never) first, then you have something that's a super-type (sub-type) of everything so you are free to cast back down (up) to an arbitrary type.The potentially unsafe step is the down cast. Up casts should always be safe.
`any` just puts you back into the dynamic typing world. It exists so TypeScript can be gradually adopted in JavaScript codebase. At least the use of `any` can be discouraged with linting. But that doesn't work for `as`. Linters don't understand the difference between safe up- and unsafe down casts. So you can only flag all uses of `as` or none.
Even with strict mode and noImplicitAny, secret any's can sneak into the codebase for the weirdest reasons (for example, poorly typed libraries. looking at you, Knex).
tseslint saves you from a ton of such gotchas.
hutao•1mo ago
> This is fundamentally different from languages like Rust, where the type system can actually guarantee that if you claim to return an Option<T>, you genuinely can’t return null, the compiler enforces the contract at the language level. Rust’s type system doesn’t just trust your annotations; it verifies them.
This design where types are present at compile-time but disappear at runtime is called type erasure, and it's extremely common. For example, Java's generics are type erased. If you have some Java class Foo<T, U>, in the bytecode it will simply become Foo, and T and U will become Object. Therefore, you cannot use runtime introspection to recover their instantiations.
The remark contrasting TypeScript to Rust seems a little confused. Rust also uses type erasure; types and lifetimes are checked by the compiler, then the compiler produces a native executable, which is just machine code and would not contain type information. Option<&T> could be treated as a pointer T*, because the niche optimization ensures that the Option::None variant is represented as 0 or NULL. If C code were to interact with Rust code via FFI, it would be able to pass a value of 0. However, Rust doesn't have a null value the way that it's commonly understood in languages such as Java, C#, or JavaScript, a distinguished value that denotes a "sentinel" reference that does not refer to any object. I would say that the null reference is semantically a higher-level concept, specific to these particular programming languages.
Philosophically, the notion of type erasure goes all the way back to Curry-style (extrinsic) typing, which is contrasted with Church-style (intrinsic) typing. For example, in Curry-style typing, the program (fun x -> x) is the identity function on all types, while in Church-style typing, each type A has its own identity function, (fun (x : A) -> x) and a program is meaningless without types.
Please correct me if I'm wrong or misunderstood!
catlifeonmars•1mo ago
And you’re right, this has nothing to do with type erasure.
auggierose•1mo ago