3 ms·

What I do: interface OutputDoesntExist { exists: false; url?: never; } Now it’s: - Optional in the union type - Always present and has t

What I do: interface OutputDoesntExist { exists: false; url?: never; } Now it’s: - Optional in the union type - Always present and has the correct type in the exists: true case - Still optional in the exists: false case, but if you try to access it you always get a type error

015a 5y ago
I like the use of 'never' over just 'undefined'; really drives home that not only is it not there, but it shouldn't exist at all in that case. I'm trying to think of a reason why the compiler couldn't allow that destructuring, implicitly type the values missing in some components of the union as 'T | ... | never', then lean on the control flow analysis it looks like we're getting in 4.6 to specify the type as the discriminated union is de-discriminated (lol). JS itself does allow the destructuring of elements missing from an object, they come out as undefined, so I don't believe there'd be any underlying issues. Hopefully we see it in 4.7!
- 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 ago
    Don’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 ago
      Immutable 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.
deleted 5y ago
[deleted]
dgreensp 5y ago
"never" is not really ever a good choice for a property/member type, because it is assignable to all types. A function that literally never returns could/should have a return type of never, for example, but if the function actually returns a value, you have a "value of type never" which is supposed be impossible, and never acts like any (because a contradiction implies anything).
- eyelidlessness 5y ago
  > "never" is not really ever a good choice for a property/member type, because it is assignable to all types. This isn’t right. It’s not assignable to anything other than never, that’s why never is so useful for this use case.

015a 5y ago

I like the use of 'never' over just 'undefined'; really drives home that not only is it not there, but it shouldn't exist at all in that case. I'm trying to think of a reason why the compiler couldn't allow that destructuring, implicitly type the values missing in some components of the union as 'T | ... | never', then lean on the control flow analysis it looks like we're getting in 4.6 to specify the type as the discriminated union is de-discriminated (lol). JS itself does allow the destructuring of elements missing from an object, they come out as undefined, so I don't believe there'd be any underlying issues. Hopefully we see it in 4.7!

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 ago
  Don’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 ago
    Immutable 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.

deleted 5y ago

[deleted]

dgreensp 5y ago

"never" is not really ever a good choice for a property/member type, because it is assignable to all types. A function that literally never returns could/should have a return type of never, for example, but if the function actually returns a value, you have a "value of type never" which is supposed be impossible, and never acts like any (because a contradiction implies anything).

eyelidlessness 5y ago
> "never" is not really ever a good choice for a property/member type, because it is assignable to all types. This isn’t right. It’s not assignable to anything other than never, that’s why never is so useful for this use case.