4 ms·
This is the second release in a row with improved control flow narrowing like this. If they’re not actively working on it I’d be surprised. Just a matter of phy
by eyelidlessness 5y ago
This is the second release in a row with improved control flow narrowing like this. If they’re not actively working on it I’d be surprised. Just a matter of physics (time).
The only underlying issue I could foresee is async. Eg narrow, await, infer. But I’d assume that affects all similar cases.
IMO this is as good a time as any to introduce an immutable-by-default mode. If you know it won’t change you can trust the previously narrowed type at any async boundary.
- nielsbot 5y agoDon’t think they can do anything that isn’t strictly a superset of JS. That said I think you can use `const` and `Readonly<T>` to get some safety against mutability.
- eyelidlessness 5y agoImmutable by default can still be a strict superset of JS. It just requires treating const assignments and function parameters as Readonly (or ReadonlyArray/ReadonlyMap/ReadonlySet) and introducing a Mutable type/mutable keyword. In my own personal projects I make nearly everything immutable at the type level and, while it makes my code safer it’s an enormous pain in the butt to type readonly on every property. As a matter of habit it has one other benefit though: you never have to worry about accepting `as const` values in function calls.