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
Problem: what does it mean to spread in these object subtypes?
For these object subtypes, any argument list translated to an array or a tuple won't ever satisfy these types.
Solution: if you ever have a type parameter constrained to something other than an Array or ReadonlyArray, and you are trying to relate to a generic rest parameter, you infer a tuple type from the matching argument and try to infer from that.
If that inference fails, TypeScript falls back to the constraint and relates against that.
Positional type arguments are problematic because it locks you down.
Using a type parameter as a default for a temporary/local type.
StrictEventEmitter
"Is this a real type!?"
Specialized subclasses:
```ts
class Box<T> { x: T }
class SpecialBox extends Box<Speical>
// How do I specialize this further without making SpecialBox generic?
class SpecialSpecialBox extends SpecialBox {
}
```
At a high level, we want to be able to place types within types.
Call-site inference for implicit
any
sThis is a demo presentation
charSet
declaration functionnoImplicitAny
onstring
, and so we change the parameter type.any
and report an error.Weird behavior for spreading arrayish types
#26110
We now allow rest parameters to have a generic type (
T
).T extends any[]
).But you can come up with several things that actually satisfy arrays.
Object subtypes:
Problem: what does it mean to spread in these object subtypes?
Solution: if you ever have a type parameter constrained to something other than an
Array
orReadonlyArray
, and you are trying to relate to a generic rest parameter, you infer a tuple type from the matching argument and try to infer from that.Union subtypes:
Named type arguments, associated types, and partial inference
In Named Type Arguments & Partial Type Argument Inference #23696, we realized that making every type parameter nameable would be problematic for existing APIs - it exposes what were thought of as mostly implementation details.
What problems were we trying to solve?
StrictEventEmitter
At a high level, we want to be able to place types within types.
Hold up though, that means in this class you can't write the following, since you don't know if
Boxified
will be further specialized.Feels strange that these can appear in the type parameter list.
One of the core differences is that we also don't do inference on these types.
Also, these must be associated with the instance.
If changing the type in the subtype changes the behavior in the supertype, then it must be a type variable.
But there are merits to just having this as an alias.
Could imagine
Also, feels strange that there is some mixing of type parameters and aliases:
The text was updated successfully, but these errors were encountered: