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
When narrowed to Promise, we reject comparisons with a number.
We use the comparable relationship to determine if we can compare two types. It is optimistic and roughly checks if one operand has overlap with the other - and allows a Promise | number to be compared with a number.
Is it meaningful to allow >= when you have an object?
Feels like it's questionable.
Can you get away with just restricting to numbers and bigints?
strings!
"We have to be more choosier when checking for overlappiness"
Kind of want to figure out a strategy where we get the base primitive type of each operand and then check if they're assignable to bigint | number, or string, and both have overlap.
Probably some subtlety - make sure to test with generics.
Improved Logic When Choosing Between Covariant and Contravariant Inferences
interfaceA{a: string}interfaceBextendsA{b: string}interfaceCextendsA{c: string}declarefunctioncast<T,UextendsT>(x: T,test: (x: T)=>x is U): U;declarefunctionisC(x: A): x is C;functionf1(a: A,b: B){constx1=cast(a,isC);// cast<A, C>constx2=cast(b,isC);// cast<A, C>// ~~~// Argument of type '(x: A) => x is C' is not assignable to parameter of type '(x: B) => x is B'.// Type predicate 'x is C' is not assignable to 'x is B'.// Property 'b' is missing in type 'C' but required in type 'B'.}
When doing type argument inference, we separate covariant inference sites from contravariant inference sites.
When deciding on what to infer, we use these to prioritize.
We try to pick covariant inferences, and by default construct a type from covariant inference candidates.
We do not use this type constructed by covariant inferences if:
the constructed type is never, or
it's not a subtype of any contravariant inference candidate.
[Editor's Note]: The intuition here is that a contravariant inference site places a hard expectation on what it can be given; if that fails, using the contravariant inference will provide a better error message.
Improve logic that chooses co- vs. contra-variant inferences #52123 added another exception here where we do not do this when the type parameter is used as a constraint of another type parameter and for that constrained type parameter, its covariant inference candidates the constructed covariant type of its constraint (i.e. the original type parameter).
So now in the assignment to x2, we choose the type A instead of C because T is used as the constraint of U, and the candidate of A would not have been assignable to
When a covariant inference is a subtype of the contravariant inference, you have a range of types you can choose from.
Doesn't solve all possible variations of this - doesn't fix the case of arbitrarily nested generic constraints.
Varying Subtype Reduction Depending on Declaration Order
declareletu: Promise<unknown>declareleta: Promise<any>// Assigned an expression that is Promise<any> | Promise<unknown>// but that will undergo subtype reduction// The type of union depends on whether a or u was declared firstletunion=// ^?// Varies between 'Promise<any>' and 'Promise<unknown>'.Math.random()>0.5
? Promise.reject<any>()
: Promise.reject<unknown>();union.then(v=>v.toString());
These differ by type ID based on where they're declared in the file and get sorted in an initial union type.
When we try to reduce the union, whichever came first "wins" because any and unknown are both (non-strict) subtypes of each other.
Unclear if you'd want unknown or any to win out. Presumably first principles would indicate unknown because it's the safer one.
Don't really have any solution here. Many similar issues show up.
Monomorphism Recap - Runtime Speed vs. Memory Usage
Stricter Relational Comparison Operators
#52036
#52048
Promise
, we reject comparisons with anumber
.Promise | number
to be compared with anumber
.>=
when you have an object?number
s andbigint
s?string
s!bigint | number
, orstring
, and both have overlap.Improved Logic When Choosing Between Covariant and Contravariant Inferences
#52111 (comment)
#52123
never
, orx2
, we choose the typeA
instead ofC
becauseT
is used as the constraint ofU
, and the candidate ofA
would not have been assignable toVarying Subtype Reduction Depending on Declaration Order
#52100
any
andunknown
are both (non-strict) subtypes of each other.unknown
orany
to win out. Presumably first principles would indicateunknown
because it's the safer one.Monomorphism Recap - Runtime Speed vs. Memory Usage
#51682
#51880
Identifier
to 2 properties?Node
.originalKeywordKind
hasExtendedUnicodeEscape
to the containing source file, turn it into a slow path during emit.The text was updated successfully, but these errors were encountered: