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

Heya Ron Buckton (@rbuckton), I've started to run the parallelized Definitely Typed test suite on this PR at 46ce88c. You can monitor the build here.

Heya Ron Buckton (@rbuckton), I've started to run the perf test suite on this PR at 46ce88c. You can monitor the build here.

Update: The results are in!

Heya Ron Buckton (@rbuckton), I've started to run the parallelized community code test suite on this PR at 46ce88c. You can monitor the build here.

Heya Ron Buckton (@rbuckton), I've started to run the extended test suite on this PR at 46ce88c. You can monitor the build here.

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

Interesting outcomes from the rwc tests:

• firebase.log: Cannot find module 'firebase' or its corresponding type declarations. - Probably not due to this change...
• chrome-devtools-frontend.log: 4 errors go away, one error changes from:

  node_modules/chrome-devtools-frontend/front_end/elements/ComputedStyleWidget.js(91,34): 
    error TS2339: Property 'spread' does not exist on type 'Promise<[any, any, any, any, any, any, any, any, any, any]>'.
  

  to

  node_modules/chrome-devtools-frontend/front_end/elements/ComputedStyleWidget.js(91,34): 
    error TS2339: Property 'spread' does not exist on type 'Promise<(CSSMatchedStyles | ComputedStyle)[]>'.
  

• prettier.log: OOM. Not sure if this is because of this change or something else, I'll investigate.

Ron Buckton (@rbuckton)
The results of the perf run you requested are in!

Comparison Report - main..45350

Download Benchmark

The OOM in Prettier doesn't seem to be related to this change, as I'm seeing it in other unrelated PRs as well.

Notes from design meeting:

• Need to see what this breaks.
  • Nothing seems broken in the RWC and User tests as is.
• Need to see if we can remove overloads.
  • I'm concerned that removing overloads for all will be a breaking change for anyone who has previously used
    explicit type arguments to overcome inference issues that this will ostensibly solve. The question is whether
    this is an acceptable breaking change.
• Maybe see if this can be leveraged by await?
  • I am exploring this in a separate PR that I will post shortly. This is likely to be a very breaking change in higher-order, since await PT where PT is a Promise<T> and T is a type variable will now produce an Awaited<T> instead of T. While this is arguably more correct (which was the case in the awaited T PR), it is also likely to be a breaking change.

I investigated whether having await return Awaited<T> would be a major breaking change in #45701 and it doesn't seem like that's the case, so I will merge the changes into this PR.

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

Heya Ron Buckton (@rbuckton), I've started to run the extended test suite on this PR at 657f0a9. You can monitor the build here.

Hey Andrew Branch (@andrewbranch), I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/110116/artifacts?artifactName=tgz&fileId=5F4D80343FB179768C7E7C97F73DA5C030AF4A59CDF0E108FC50B64AF7E7121F02&fileName=/typescript-4.5.0-insiders.20210909.tgz"
    }
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@4.5.0-pr-45350-27".;

If anyone in the community heavily uses await with generics and/or Promise.all, please give the above build a try and let me know your experience.

I did a quick search for Promise.all usages in the Google code base internally and only found a handful (~10) of usages with more than 1 generic parameter. We should be fine here.

To check usages of await with generics we will have to actually upgrade TypeScript and see where the builds break, I think. We'll probably report that together with other findings.

Hello everyone,

Not sure if this is the correct place to bring this up but the Awaited<T> type as-is broke our build after upgrading from typescript 4.4.3 to 4.5.2.

For reference, here is what Awaited<T> looks like:

/**
 * Recursively unwraps the "awaited type" of a type. Non-promise "thenables" should resolve to `never`. This emulates the behavior of `await`.
 */
type Awaited<T> =
    T extends null | undefined ? T : // special case for `null | undefined` when not in `--strictNullChecks` mode
        T extends object & { then(onfulfilled: infer F): any } ? // `await` only unwraps object types with a callable `then`. Non-object types are not unwrapped
            F extends ((value: infer V) => any) ? // if the argument to `then` is callable, extracts the argument
                Awaited<V> : // recursively unwrap the value
                never : // the argument to `then` was not callable
        T; // non-object or non-thenable

The problem is that we have a custom Promise class (AbortablePromise) and its then function accepts a onfulfilled callback that do not exactly match the condition F extends ((value: infer V) => any).

Our then is declared like this:

  public then<TResult1 = T, TResult2 = never>(
    onfulfilled?: ((value: T, abortController: AbortController) => TResult1 | PromiseLike<TResult1>) | undefined | null,
    onrejected?: ((reason: any) => TResult2 | PromiseLike<TResult2>) | undefined | null
  ): AbortablePromise<TResult1 | TResult2>;

So onfulfilled in our case is (value: T, abortController: AbortController) => TResult1 | PromiseLike<TResult1>) which does not match (value: infer V) => any

Hence, Awaited<T> where T is an AbortablePromise always returns never.

Would it be possible to make the type condition more flexible in Awaited<T> to enable these promise extensions and still have the type be compatible with Promise.all, Promise.race, etc?

It would be helpful to add some documentation about this on the Utility types page, not just in the 4.5 release notes that aren't part of the docs search.