Repository navigation
Missing overload method on union types #60006
Description
🔎 Search Terms
overlaod union
🕗 Version & Regression Information
This changed between versions ______ and _______This changed in commit or PR _______- This is the behavior in every version I tried, and I reviewed the FAQ for entries about overload
I was unable to test this on prior versions because _______
⏯ Playground Link
💻 Code
function groupBy<T>(array: Array<T>| ReadonlyArray<T>, key: any): Map<any, Array<T>> {
return array.reduce<Map<any, Array<T>>>((acc, element) => {
const k = typeof key === 'function' ? (key as (element: T) => any)(element) : element[key as keyof T];
let group = acc.get(k);
if (!group) {
acc.set(k, group = []);
}
group.push(element);
return acc;
}, new Map<any, Array<T>>());
}🙁 Actual behavior
getting the errors:
Expected 0 type arguments, but got 1.
Type 'T' is not assignable to type 'Map<any, T[]>'.
Expected 0 type arguments, but got 1.
Property 'get' does not exist on type 'T'.
Property 'set' does not exist on type 'T'.
🙂 Expected behavior
Allowing the use of the 3rd overload method reduce<U> of Array / ReadonlyArray
Additional information about the issue
No response
Activity
jcalz commentedon Sep 19, 2024
There doesn't seem to be a reason to write
Array<T> | ReadonlyArray<T>since that's equivalent toReadonlyArray<T>as shown in this playground linkBut I kind of thought #53489 took care of these "union of array" things.
wheeOs commentedon Sep 19, 2024
Joe Calzaretta (@jcalz)
true that, thanks for pointing that out. I initially wrote the function for
Array<T>, then I had to modify it forReadonlyArrayand it ended up like that, but apparently unnecessarilyRyanCavanaugh commentedon Sep 19, 2024
You're reporting this issue specifically?
wheeOs commentedon Sep 19, 2024
Ryan Cavanaugh (@RyanCavanaugh) yes the code sample can be reduced to that
Andarist commentedon Sep 19, 2024
This was released in TS 5.2 and it's only about fallback signatures. It applies to situations when a signature can’t be found in a normal way but we can see that TS was able to find some signatures here even before that: TS 5.1 playground.
This case loses the relevant signatures in (somewhat complicated)
getUnionSignatures. This function is able to compute some signatures (2 to be precise) in this case though so the referenced improvement from TS 5.2 doesn't even kick-in.weswigham commentedon Sep 23, 2024
Yeah, the fallback logic is for unions of arrays over differing element types (to consider them close enough to a single array over the union of both element types) - this example is differing array types over the same element type. We end up saying we can't consider the
reduceoverload with a type argument as identical (rightly so) across the two array types because the 3rd argument of one callback isT[]while the other isreadonly T[]. It's interesting here because we could just subtype reduce the signatures in this case and get a canonical signature set out pretty easily, which is what I've proposed we do opportunistically in #60036weswigham commentedon Sep 24, 2024
For now, we've chosen to leave this behavior as-is, unless we get some more frequent/compelling examples that require unifying multiple generic signatures to the subtype rather than dropping them, as we do today.