4 ms·
Those two types are indeed equivalent by themselves. The problem comes when you want to store them somewhere nullable. `zero | one | two | zero` flattens back d
by Nullabillity 4y ago
Those two types are indeed equivalent by themselves. The problem comes when you want to store them somewhere nullable. `zero | one | two | zero` flattens back down to `zero | one | two`, you can't distinguish between the two zero/null cases.
On the other hand, `Option<Option<one | two>>` allows you to distinguish between None and Some(None).
This makes union types unsound in the presence of type parameters/generics.
TypeScript supports both anyway, because Hejlsberg cares more about being able to type existing JS antipatterns than about providing a sound type system.
- valenterry 4y ago> This makes union types unsound in the presence of type parameters/generics. I'm not sure if "unsound" is a good adjective here. There are cases where this is actually desired behaviour and the rules can definitely be "sound". For example, I might want to know what errors can appear, but not care where they come from. So `ErrorA | ErrorB` is what I want to see, not some nested structured that allows me to differentiate where ErrorA came from in case that there are multiple possible options.
- ObscureScience 4y agoI did not catch from you comment if you knew, but "sound" and "unsound" are specific concepts in type theory, and they are binary properties. A system either is or is not sound.
- valenterry 4y agoYeah I know that. So: > This makes union types unsound in the presence of type parameters/generics. Sounds a bit strange to me. Why would union types + type parameters be generally unsafe? I doubt that that's true.
- trenchgun 4y agoSound type system is not one of the design goals of TypeScript https://effectivetypescript.com/2021/05/06/unsoundness/ https://effectivetypescript.com/2021/05/06/unsoundness/