@typescript-bot perf test
@typescript-bot run dt
@typescript-bot test this
@typescript-bot user test this

Heya@rbuckton, I've started to run the parallelized Definitely Typed test suite on this PR at46ce88c. You can monitor the buildhere.

Heya@rbuckton, I've started to run the perf test suite on this PR at46ce88c. You can monitor the buildhere.

Update:The results are in!

Heya@rbuckton, I've started to run the parallelized community code test suite on this PR at46ce88c. You can monitor the buildhere.

Heya@rbuckton, I've started to run the extended test suite on this PR at46ce88c. You can monitor the buildhere.

The user suite test run you requested has finished andfailed. I've opened aPR 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.

@rbuckton
The results of the perf run you requested are in!

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 forall 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 byawait?
  • 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, sinceawait PT wherePT is aPromise<T> andT is a type variable will now produce anAwaited<T> instead ofT. While this is arguably more correct (which was the case in theawaited T PR), it is also likely to be a breaking change.

I investigated whether havingawait returnAwaited<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 perf test
@typescript-bot run dt
@typescript-bot test this
@typescript-bot user test this inline

Heya@rbuckton, I've started to run the extended test suite on this PR at657f0a9. You can monitor the buildhere.

Hey@andrewbranch, I've packed this intoan installable tgz. You can install it for testing by referencing it in yourpackage.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 runningnpm install.

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

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

I did a quick search forPromise.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 ofawait 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 theAwaited<T> type as-is broke our build after upgrading from typescript 4.4.3 to 4.5.2.

For reference, here is whatAwaited<T> looks like:

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

The problem is that we have a custom Promise class (AbortablePromise) and itsthen function accepts aonfulfilled callback that do not exactly match the conditionF extends ((value: infer V) => any).

Ourthen is declared like this:

publicthen<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>;

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

Hence,Awaited<T> whereT is anAbortablePromise always returnsnever.

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

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