Promise intersection with primitive results in wrong awaited type

[Azarattum]

Bug Report

When we make an intersection of a promise with a primitive type like Promise<T> & T (where T is primitive (non-object)), the resulting type from await (Promise<T> & T) is wrong (still contains a promise). This is clearly a bug since Awaited<Promise<T> & T> and (Promise<T> & T).then(x => {}) behave correctly (the result is only T). The issue is only observed when using the await keyword.

The types arrangement might seem arbitrary, but it has a valid use case which is provided in the playground link below.

🔎 Search Terms

PROMISE & PRIMITIVE, PROMISE INTERSECTION, AWAITED TYPE, INCONSITENT THEN AND AWAIT

🕗 Version & Regression Information

Tested only versions available on playground!

• This changed between versions 4.5.5 and 4.7.0-dev.20220503. 4.4.4 and lower are unaffected by this bug.

⏯ Playground Link

Playground link with relevant code

💻 Code

type A = Promise<number> & number;
const a = {} as A;

const b = await a;
type B = typeof b; // B should be "number", but it is "Promise<number> & number"!

a.then((c) => {
  type C = typeof c; // C is "number" (which is corrent)
});

type D = Awaited<A> // D is "number" (which is corrent)

🙁 Actual behavior

Type B still contains Promise<number> despite of the value being awaited.

🙂 Expected behavior

In the example above B has to be equal to C and D.

[Azarattum]

#45350 this is probably related. However, as shown before, the Awaited itself works correctly.

[fatcerberus]

I don’t understand (even with your playground example) why you would ever write Promise<number> & number. This type represents a value that is simultaneously both a promise object and a primitive number, which is impossible.

[jcalz]

The code in there seems to be using symbol, but there are no values which are both symbols and promise objects. Could you clearly articulate the use case in words?

Even better, could you show a working example of your use case at runtime? Your playground link uses {} as the runtime value which won't actually work at runtime. Like, forget the TS types for a bit, what kind of JS behavior are you trying to support?

[andrewbranch]

It does seem theoretically wrong, but yeah, unless there is a real-world use case I doubt we’ll prioritize a change here.

[Andarist]

I don't think this would be a hard fix - at the moment this is somewhat explicitly called out to be invalid in one of the comments:
https://github.dev/microsoft/TypeScript/blob/8f56f6b49d2fb282ff95df64f62dab2947004e95/src/compiler/checker.ts#L36317-L36321

Probably one of the required changes to make this work would be to tweak the related logic in the getPromisedTypeOfPromise here:
https://github.dev/microsoft/TypeScript/blob/8f56f6b49d2fb282ff95df64f62dab2947004e95/src/compiler/checker.ts#L36265-L36268

I could take a stab at this - if only somebody would confirm that this behavior needs to be adjusted. I also don't see though how this could be utilized in the real-world code so far.

[andrewbranch]

I did a quick experiment monkeypatching String.prototype.then to see if it would be called by Promise.resolve (or await, which uses the algorithm of the former). It did not. It’s pretty hard to follow but I think I found this in the spec: https://tc39.es/ecma262/#sec-promise-resolve-functions

8. If Type(resolution) is not Object, then
   a. Perform FulfillPromise(promise, resolution).
   b. Return undefined.

The only way I can interpret string & Promise<string> is a value that is definitely the primitive string but also manages to satisfy the Promise interface structurally, which perhaps you could do with a horrifying regimen of monkeypatching. The spec and my experiment seem to agree that such a value (the stuff of nightmares) would in fact emerge unchanged from await. So the type is correct.

[Azarattum]

Thank you all for your feedback.

@andrewbranch I don't think this issue should be closed. I just made a full example use case which roughly replicates what I'm trying to achieve in my project. I'm working on a custom asynchronous store for Svelte similar to this one or this one. The idea behind it is to abstract away API interactions, so the store can manage everything. To achieve that I'm using a data structure which I call RichPromise which is basically Promise<T> & T of anything (including primitives). This is achieved by constructing a special prototype chain which includes the original object's prototype, bound methods for primitives, overrides such things as [Symbol.toPrimitive] and valueOf, and adds then, catch, finally to mimic a promise behavior (for implementation details see enrich function in the example). Because the original prototype is included in RichPromise's chain enrich(Promise.resolve("2"), "1") instanceof String is true.

This has one caveat though. When we first look at out rich promise (before any api calls resolve), there is no data to be concatenated with a promise, so we pair it with loading symbol placeholder. This way the type becomes Promise<T> & (T | typeof loading). I choose to use a symbol, so we can infer the loading state by type with if (richPromise == loading) which works because of the [Symbol.toPrimitive] override. So, it is must have for primitive types to work correctly because the guard above only works if we use unique symbol, but not Symbol which makes sense. However as we do not have unique Symbol as an object there is no other way to solve it.

This whole approach was chosen to elegantly support 2 different rendering strategies in svelte templates:

<!-- Strategy 1 -->
<p>
  {#if $store != loading}
    {$store}
  {:else}
    <!-- Is shown only the first time -->
    Loading
  {/if}
</p>

<!-- Strategy 2 -->
<p>
  {#await $store}
    <!-- Is shown every time new data starts loading -->
    Loading
  {:then data}
    {data}
  {/await}
</p>

In the linked example I'm trying to mimic something similar to svelte stores without the framework. If you run the code, you'll see the showcases of the two strategies shown above:

Showcase loading strategy 1
Loading...
(3) ['super', 'important', 'data'] 'Data: super important data'
(3) ['super', 'important', 'data'] 'Data: super important data'
(3) ['some', 'changed', 'data'] 'Data: some changed data'

Showcase loading strategy 2
Loading...
(3) ['super', 'important', 'data'] 'Data: super important data'
(3) ['super', 'important', 'data'] 'Data: super important data'
Loading...
(3) ['some', 'changed', 'data'] 'Data: some changed data'
(3) ['some', 'changed', 'data'] 'Data: some changed data'

Note that in a real scenario the same data would not be rendered twice.

Anyway besides all of that, this is INCONSISTENCY (between then, await, Awaited) and should be considered a bug. Moreover, since this was introduced just recently it cannot be seen an intended behavior.

[Azarattum]

Also, if we had a way to

data: A | B;
if (data != B) {
  data: A;
}

where B extends object. That would also solve my particular use case. But I would rather get the original issue solved for the sake of consistency.

If anyone knows if the snippet above is achievable (without changing an operator or using a function) please let me know.

Fun fact

I also tried to use document.all and %GetUndetectable() for prototyping a falsy object to a promise, so this would be possible:

{#if $store}
  {$store}
{:else}
  Loading
{/if}

{#await $store}
  Loading
{:then data}
  {data}
{/await}

But it was a little bit to far... And there were some problems with promises not being detected since typeof document.all returns undefined and not an object. So I decided to go ahead with the symbol approach.