Closed
Description
Unioning Signatures Across Array
Methods
interface Fizz {
id: number;
fizz: string;
}
interface Buzz {
id: number;
buzz: string;
}
([] as Fizz[] | Buzz[]).filter(item ==> item.id < 5); // not allowed
- Long-standing issues with typing unions of array methods.
- We have special logic to combine single signatures across unions.
- Only single signatures.
filter
,find
,reduce
have multiple signatures.- At least in ES6.
- Issues around setting contextual types during inference and not being able to backtrack.
- Idea: arrays are special - maybe special-case these?
- Could this be extended to more generally apply to instantiations of the same generic type?
- Arrays have to be handled special-case in the general case due to hard-coded variance assumption.
- Have to do variance calculation of each type parameter in the signature - could do it, don't do it today.
- Non-trivial amount of work.
- Also - downside of this is that the output type would be awkward, possibly questionable.
- Users hit this very often - would like to get this fixed.
- Long-term do we want the general solutions?
- Possibly - the two solutions (doing the same thing for every type, resolving across unions) are possibly expensive.
- Let's not let perfect be the enemy of good for now.
Slow Type-Checking with Large Enum
- Have a huge
enum
type - 1500 elements. - Have something like
Record<A, B>[A]
whereA
is thisenum
. - Original logic to construct this was to create the candidate set for each
K
inA
asRecord<A, B>[K]
- then reduce the overall array. - New logic - cache the immediate last type, see if the new type is identical. If so, don't add.
- Great optimization, dropped to 50% of the time, but still long check time.
- Also noticed that the original case was a
Partial<...>
of the original.- If calling
getUnionType
with a pair of types (two types), create a cache key more quickly.
- If calling
- We do spend a lot of time flattening out unions of unions.