I think this is a duplicate of #7294

Duplicate of #7294 (see comment). Related to #29011.

Mentioned in documentation as caveats for improved behavior for calling union types:

This new behavior only kicks in when at most one type in the union has multiple overloads, and at most one type in the union has a generic signature. That means methods on number[] | string[] like map (which is generic) still won’t be callable.

Is this really a duplicate? The 'duplicate' issue is marked as closed, but this issue still exists. If it really is a duplicate, can we re-open #7294 to handle this case?

The reason stated by @weswigham for not unifying for generic signatures with multiple signatures is that:

Well, it's because we don't really know if the generics are the same (and so because of that we'd opt to make the parameter type T & T' instead and combine the type parameter lists to <T, T'>), so we opt to not allow the call.

But for function signatures originating from the same declaration we can be sure that we are talking about the same overload signatures in the same order and with the same generic parameters. As long as the generics don't have constraints, unifying the signatures should be safe IMO.

I think that unifying for this case would satisfy a lot of use cases. Array and Promise would benefit from this and those are the usual place people run into this limitation.

Yeah, I have a change around here somewhere that allows it for exactly that situation rummages through bin of old PRs

@weswigham What was wrong with it? Why did it get stuck ? Can we revive it :D ?

#31023 contains the relevant code. It's a bit old, and some parts of it are probably no longer needed thanks to some other signature resolution changes we made (namely the base signature stuff should no longer be needed).

Cool! So is this planned for a release in the future I'm guessing? I wanted to have a look at this over the weekend but glad to see it already there and we will get eventually :)

Looks like my issue #36307 talks about pretty much the same behavior, linking for discoverability. Glad to see there's been some movement!

Until this gets fix you can do something like:

const arr: number[] | string[] = [];
// Add as any[]
(arr as any[]).map((a: number | string, index: number) => { 
    return index
});

I got similar error while calling map on Dictionary<CustomType[]>, hope this gets fixed soon, currently used lodash-es's map to avoid this.

This issue is closed, but the reduce() example persists:

const arr: number[] | string[] = [];

arr.reduce((acc: Array<string>, a: number | string, index: number) => {
  return []
}, [])

/* This expression is not callable.
  Each member of the union type '...' has signatures,
  but none of those signatures are compatible with each other. */

Playground link

I'm super excited about the improvements in #31023! But it doesn't seem to have completely resolved the issues with calling array methods on unions of arrays.

I tested a few common array methods and found the following results:

• .map() works
• .forEach() works
• .includes() works
• .indexOf() works
• .findIndex() works
• .some() works
• .every() does not work
• .filter() does not work
• .find() does not work
• .reduce() known not working (issue)

I've created a new issue to track the remaining functionality.