I think the suggestion is for typescript to have one none type equal to undefined | null. The type checker could not error on undefined when null is required or vice versa.
Then code should use != null comparisons which match the none types semantics without needing runtime code generation.
I think this would violate another typescript principles that existing libraries and patterns should be expressable in typescript.
Some schmuck wrote a library that accepts null but not undefined so typescript has to distinguish them.
Nah. This doesn’t change the semantics of JS. As numerous sibling commentors pointed out, distinguishing between null and undefined is not a good idea in normal JS either. This was simply a bad design decision in TS, especially given that CoffeeScript has done it “right” many years before.
Unfortunately I feel like every language design team prefers to learn their mistakes on their own instead of learning from others (with the usual “our language is different” excuse).
