Array.from(it: Iterable<X> | Iterable<Y>) fails; […it] works but returns Array<X | Y>; both should return Array<X> | Array<Y>

[gormster]

🔎 Search Terms

Array.from is currently declared as

from<T>(iterable: Iterable<T> | ArrayLike<T>): T[];

This means that unions of distinct iterable types cannot be turned into arrays of the same type.

let foo: Iterable<string> | Iterable<number> = /* ... */;
let q: Array<string> | Array<number> = Array.from(foo); // Fails type checking, cannot find overload (2769)

The array splat operator has a different problem: it tries to create an array that is a union of both types.

let foo: Iterable<string> | Iterable<number> = /* ... */;
let q: Array<string> | Array<number> = [...foo]; // Fails type checking, not assignable to type (2322)

My instinct is that there should be some way to use variadic types here, but tbh I don't really know how.

Does this need new syntax? Or does it work within the existing type system?

🕗 Version & Regression Information

Since at least 4.0; prior to 4.0 it still fails but Array.from did not support taking an Iterable.

Still around in 6.0.0-dev.20251009

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.9.3&ssl=19&ssc=1&pln=11&pc=1#code/PTAEHUFMBsGMHsC2lQBd5oBYoCoE8AHSAZVgCcBLA1UABWgEM8BzM+AVwDsATAGiwoBnUENANQAd0gAjQRVSQAUCEmYKsTKGYUAbpGF4OY0BoadYKdJMoL+gzAzIoz3UNEiPOofEVKVqAHSKymAAmkYI7NCuqGqcANag8ABmIjQUXrFOKBJMggBcISGgoAC0oACCbvCwDKgU8JkY7p7ehCTkVDQS2E6gnPCxGcwmZqDSTgzxxWWVoASMFmgYkAAeRJTInN3ymj4d-jSCeNsMq-wuoPaOltigAKoASgAywhK7SbGQZIIz5VWCFzSeCrZagNYbChbHaxUDcCjJZLfSDbExIAgUdxkUBIursJzCFJtXydajBVDtUAAMXgGAAvKAAJIKMgMaTuAA8glQlE4zAAfKAAD5MllszmcdiIaTffkAbmCyS4sHqjTQZDwFTIrLwVLYiAAFMlaflqbSAJSgADeihKJXcNAAjqatTquTzhoKRa6mBzJdLZaAGT68AFkvqjRaFQBfRXK1WZDXEBZ1SPwU00+CWm12tyQJ0u7W+7m8gXCypFvB+qUysiChkAbQCzeN8AAujHgiocM0PGQvIh4H02RwaF83GZmOwGMxIPxYNB1IkR3oRF4AEQAUVWDEQC3066S2PX4AcqAA5MIAHKQCTroIqADyXzI70Ec60+auqEcClc0jwUAnEHHRhiwfQUAQRBoWES5xwkIdohEAwOGxFMWDYLhuCCEogA

💻 Code

type Foo = Iterable<string> | Iterable<number>;

function tryArrayFrom(foo: Foo) {
    let q: Array<string> | Array<number> = Array.from(foo);
}

function trySplat(foo: Foo) {
    let q: Array<string> | Array<number> = [...foo];
}

🙁 Actual behavior

for tryArrayFrom
No overload matches this call.
Overload 1 of 4, '(iterable: Iterable | ArrayLike): string[]', gave the following error.
Argument of type 'Foo' is not assignable to parameter of type 'Iterable | ArrayLike'.
Type 'Iterable' is not assignable to type 'Iterable | ArrayLike'.
Type 'Iterable' is not assignable to type 'Iterable'.
The types returned by 'Symbol.iterator.next(...)' are incompatible between these types.
Type 'IteratorResult<number, any>' is not assignable to type 'IteratorResult<string, any>'.
Type 'IteratorYieldResult' is not assignable to type 'IteratorResult<string, any>'.
Type 'IteratorYieldResult' is not assignable to type 'IteratorYieldResult'.
Type 'number' is not assignable to type 'string'.
Overload 2 of 4, '(arrayLike: ArrayLike<string | number>): (string | number)[]', gave the following error.
Argument of type 'Foo' is not assignable to parameter of type 'ArrayLike<string | number>'.
Property 'length' is missing in type 'Iterable' but required in type 'ArrayLike<string | number>'.

for trySplat
Type '(string | number)[]' is not assignable to type 'string[] | number[]'.
Type '(string | number)[]' is not assignable to type 'string[]'.
Type 'string | number' is not assignable to type 'string'.
Type 'number' is not assignable to type 'string'.

🙂 Expected behavior

Array.from a union of Iterables should return a union of Arrays.

Additional information about the issue

No response

[gormster]

Oh, who would have thought I'd found something that would help right in the Handbook, while trying to solve a different problem:

When conditional types act on a generic type, they become distributive when given a union type. For example, take the following:

type ToArray<Type> = Type extends any ? Type[] : never;

If we plug a union type into ToArray, then the conditional type will be applied to each member of that union.

type ToArray<Type> = Type extends any ? Type[] : never; 
type StrArrOrNumArr = ToArray<string | number>;
type StrArrOrNumArr = string[] | number[]

https://www.typescriptlang.org/docs/handbook/2/conditional-types.html#distributive-conditional-types

So, it's clear that Array.from<T> should return ToArray<T> (where ToArray is defined as something like in the example).

Here's a playground link showing that it does seem to work within the current type system:

https://www.typescriptlang.org/play/?ts=5.9.3#code/PTAEHUFMBsGMHsC2lQBd5oBYoCoE8AHSAZVgCcBLA1UABWgEM8BzM+AVwDsATAGiwoBnUENANQAd0gAjQRVSQAUCEmYKsTKGYUAbpGF4OY0BoadYKdJMoL+gzAzIoz3UNEiPOofEVKVqAHSKymAAmkYI7NCuqGqcANag8ABmIjQUXrFOKBJMggBcISGgoAC0oACCbvCwDKgU8JkY7p7ehCTkVDQS2E6gnPCxGcwmZqDSTgzxxWWVoASMFmgYkAAeRJTInN3ymj4d-jSCeNsMq-wuoPaOltigAKoASgAywhK7SbGQZIIz5VWCFzSeCrZagNYbChbHaxUDcCjJZLfSDbExIAgUdxkUBIursJzCFJtXydajBVDtUAAMXgGAAvKAAJIKMgMaTuAA8glQlE4zAAfKAAD5MllszmcdiIaTffkAbmCKmSXFg9UaaDIeAqZFZeCpbEQAApkrT8tTaQBKUAAbxmJTckBoAEczdrdVyecNBSK3UwOZLpbLQAzfXgAskDcbLQqVABfRVgZXmNWZTXEBZ1KPwM00+BW20qe0O52unV+7m8gXCyplvD+qUysiChkAbQC7ZN8AAujGwPHFBSiN54KGOftm8SUGsFDxhGY8KAAPyTltd0BmziQPRkBWD3DwZnfcWQMftCf7cGrGfcOecBfLw+s9kn8fr-pb767yk4Ee154UeIXzPYNJ0va9b3vGtdX-QDTyIQUNw-HcE28NRhFEChuBRepamgMFcwHSkKmgQR4FzECf0fY8PUrasA0beVgiTVUGi8RxdX1JAx35Q15CPZ8zUosVn24i1BN-d0cEY5iUzEWtOMQbjeOE9wzSokSpOrUMYJffkxKgv0pIVGTWLkjiDSUvin1U0V+M5TSfT-ADdP00cHOHNzBVtIsVAAAVQQRSgoZgBicRQiycVB8S8UNw0jKzjwtBV+xMxoACork9PkAHEUUNfNwvtE0yENdx0iSVIWwAIgqKr+CqgAhOrQCqgBhKquytPAKBgVwKGSpiVRTDL6O+XLOHym1CpKYrSsdEQKtAFsAEZ+AAJn4ABmTrQG63qRAGxRUs4DKEGleBxsm7yivgEqyquRaK2GS6LS6nroiuBUi1m+6vCJUayBet79s4Q77oIECnpyvKksUe6nRAgGXoVe6zuBEC0YumGFTh+aCDdED2KYBTDQIWH4YJhkib1SMnVh4pMYJ0QEB1SBVWgBcMhZAhIsgVwGGEQ0oZGEUAYtVdcZoRmdUJ+TI0x+njvmdR4keFwkHynNaSmosEVAQ0AFk6kwAJWR4DWrUFAAGAIAFYCqLCLHWi+YvvtWNwRIlBrsd0BIpdp03ZKeN+xUAAJSA8H4eQAHI50yytVzohtvlXABCSW-fVxBKbM4mLOF5PAybUmVbV82jVeuUgA

[jcalz]

This is a specific instance of #52295. Conceptually every function could/should distribute over unions in their arguments, but it would be a lot more work for the type checker. Here you're just talking about Array.from(), but it's the same basic situation: making the call signature more complicated has a performance impact. Unless people regularly call Array.from() on unions, the benefit probably wouldn't outweigh the costs. (There's also the possibility that the more complicated call signature would break real world code.)

I'd say if you want this in your own code base, you could just merge in the following call signature (or something like it) locally:

interface ArrayConstructor {
    from<T extends Iterable<any>>(iterable: T): T extends Iterable<infer U> ? U[] : never;
}

[RyanCavanaugh]

+1 to everything in jcalz's comment

#52295 is unlikely to ever happen (too easy to combinatorially blow up, and too much weirdness having a combinatorial cutoff), so we should think about which built-in APIs need a distributing signature like this and which don't, or if there's a cleaner mechanism to consider.