You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"Well, we're consistent, but we don't narrow constraints."
But sometimes we do intersections, sometimes we narrow unions, etc.
Today:
functionf<T>(x: T){if(typeofx==="string"){// 1: 'x' has type 'T & string' here.}if(x!=null){// 2: nothing happens here}}
At 1, treating this as an intersection here is likely correct.
But the problem is that we're not sure that, when performing instantiation, you really want to absorb more general types to their more derived types (e.g. number & 100 becomes 100) because this can affect contextual types, etc.
It seems like it's ostensibly okay for intersections; not necessarily for unions.
You are strictly losing types from unions.
At 2, you want to find a way to remove null and undefined.
Can use the NonNullable type helper within the compiler.
Narrowing & Combining Higher Order Types
#20673
#21369
#15100
#22096
#21182
#15643
#19469
#14967
#15376
#18902
Today:
1
, treating this as an intersection here is likely correct.number & 100
becomes100
) because this can affect contextual types, etc.2
, you want to find a way to removenull
andundefined
.NonNullable
type helper within the compiler.Should we allow indexed access types on nullable
#14366
!
type operator since that's what people originally asked for.Type imports at arbitrary locations
#14844
import
operator that returns aPromise
?esModuleInterop
.import("foo").default
forexport =
.JSDoc type imports
#22160
typedef
s with the new syntax.Generics in JSX
#22415
The text was updated successfully, but these errors were encountered: