Add variadic tuple overload to Promise.all

[Anders Hejlsberg (ahejlsberg)]

Experiment for now. Similar to #39336, but with a different overload definition.

[Anders Hejlsberg (ahejlsberg)]

TypeScript Bot (@typescript-bot) test this
TypeScript Bot (@typescript-bot) user test this
TypeScript Bot (@typescript-bot) run dt

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the extended test suite on this PR at 00fa5b8. You can monitor the build here.

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized Definitely Typed test suite on this PR at 00fa5b8. You can monitor the build here.

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized community code test suite on this PR at 00fa5b8. You can monitor the build here.

[Anders Hejlsberg (ahejlsberg)]

TypeScript Bot (@typescript-bot) user test this

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized community code test suite on this PR at 00fa5b8. You can monitor the build here.

[TypeScript Bot (typescript-bot)]

The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master.

[Anders Hejlsberg (ahejlsberg)]

Ron Buckton (@rbuckton) Interesting that this doesn't seem to break VSCode. In fact, best I can tell, none of the differences in the user tests appear to be caused by adding the extra overload.

[Anders Hejlsberg (ahejlsberg)]

TypeScript Bot (@typescript-bot) test this
TypeScript Bot (@typescript-bot) user test this
TypeScript Bot (@typescript-bot) run dt

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized Definitely Typed test suite on this PR at 4f5b329. You can monitor the build here.

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized community code test suite on this PR at 4f5b329. You can monitor the build here.

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the extended test suite on this PR at 4f5b329. You can monitor the build here.

[Anders Hejlsberg (ahejlsberg)]

Latest commit removes the old overloads. This is a breaking change for calls with explicit type arguments, but it may still be worth it for the simplicity and improvement in error reporting that it brings. Re-running tests to see the effects.

[Ron Buckton (rbuckton)]

I'm still very wary of Awaited<T>. The definition of Awaited<T> has some strange effects when not in strictNullChecks. Jack Bates (@jablko) also looked at this in several PRs (#35284, #33707, #33055) and made a note here: https://github.com/microsoft/TypeScript/pull/35284/files#diff-a6b488d9bd802977827b535a3011c1f3R1381

Basically, Awaited<undefined> and Awaited<null> return unknown when not in strictNullChecks, which seemed surprising.

I'd also looked into adding Awaited<T> into the core library with a definition that was intended to give a more correct answer WRT non-promise "thenables" in #21613:

type Awaited<T> =
    T extends { then(onfulfilled: (value: infer U) => any): any; } ? U :
    T extends { then(...args: any[]): any; } ? never :
    T;

This definition represented the minimal case that was consistent with await (aside from recursive unwrap), as the following is currently an error in TypeScript:

declare const p: { then(): void };
async function f() {
  await p; // Type of 'await' operand must either be a valid promise or must not contain a callable 'then' member.
}

[Ron Buckton (rbuckton)]

Ah, disregard the comment about undefined, as I see that it is included in your changes.

We could theoretically bake in a few levels of nesting. Its fairly trivial to result in Promise<Promise<T>> due to inference, though higher levels are much less frequent. Until such time as we can reconsider awaited, perhaps we should consider a definition like this:

type Awaited<T> =
    T extends undefined ? T :
    T extends PromiseLike<PromiseLike<infer U>> ? U :
    T extends PromiseLike<infer U> ? U :
    U;

While more verbose, it does handle both the common cases (T, Promise<T>) and the frequent doubly-nested promise case due to inference (Promise<Promise<T>>).

[Ron Buckton (rbuckton)]

I would propose we move this to es5.d.ts so that it sits alongside PromiseLike, as it has no dependency on Promise directly.

[ExE Boss (ExE-Boss)]

This can probably be reevaluated now that #45350 has been merged.

[Nathan Shively-Sanders (sandersn)]

This experiment is pretty old, so I'm going to close it to reduce the number of open PRs.