let promises be unions

[zpdDG4gta8XKpMCd]

nightly build, September 7, 2016

currently in order for async/await to work it has to be a solid interface with a then method, await doesn't accept a union that has a callable then, please allow unions for promises

// tsconfig.json
{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es6",
        "noLib": true
    }
}

const enum PromisedKind { Resolved, Unresolved }

interface Thenable<a> {
    then<b>(onfulfilled?: (value: a) => b | Promise<b>, onrejected?: (reason: any) => b | Promise<b>): Promise<b>;
    then<b>(onfulfilled?: (value: a) => b | Promise<b>, onrejected?: (reason: any) => void): Promise<b>;
}

type Promise<a> = Resolved<a> | Unresolved<a>;

interface Resolved<a> extends Thenable<a> {
    kind: PromisedKind;
    value: a;
}

interface Unresolved<a> extends Thenable<a> {
    kind: PromisedKind;
    thens: { (value: a): void; }[];
}

interface Array<a> {}
interface Boolean {}
interface Function {}
interface Number {}
interface Object {}
interface RegExp {}
interface String {}
interface IArguments {}
var String: StringConstructor;
interface StringConstructor {
  new (value?: any): String;
  (value?: any): string;
  prototype: String;
  fromCharCode(...codes: number[]): string;
}


declare const value: Promise<number>;

async function test() {
    void value.then(x => { }); // <-- then exists and is callable
    return await value; // Operand for 'await' does not have a valid callable 'then' member.
}

[jods4]

Actually, you can await anything, not only promises.
It should behave as if you did await Promise.resolve(x) (note that if x was a promise already, Promise.resolve(x) should return x itself).

EDIT: well, that's the specified JS behavior, of course. Now the question is: in a typed world, does it make sense or do we want to be more strict and await Promises only (in the same way TS refuses to do "x" * 2 when it's runnable JS)?
I would argue that it is sometimes useful to do as @Aleksey-Bykov showed and mix sync and async implementations. I personnally do that in a rule engine I wrote. I don't think it is dangerous from a typing point of view.

EDIT 2: thinking some more... maybe it should raise a warning if you await something that cannot be a Promise/Thenable?
So going back to OP: let a: X|Y = await Promise<X>|Y is ok and works, let a: Y = await Y actually works but is dubious and should be flagged as an error?

[aluanhaddad]

well, that's the specified JS behavior, of course

@jods4 I am not sure I understand this statement. JavaScript does not have interfaces.

[jods4]

@aluanhaddad I meant that JS supports awaiting any value, not only promises/thenable. It is not an error to await 4.

[Arnavion]

maybe it should raise a warning if you await something that cannot be a Promise/Thenable?

#8310

[jods4]

@Arnavion Thanks for the link. I see this was beaten to death in several issues already. So I guess we should be able to await anything!

I noticed @RyanCavanaugh said in that thread:

We clearly want to allow await T | Promise<T>

But as @Aleksey-Bykov says, the following code trips up the type checker:

let x: number | { then(): number };
async function f() {    
    return await x;  // Error
}

I think that TS should distribute the await operation and deduce that the result is number | number, well number.

[aluanhaddad]

@jods sorry, it appears I misunderstood the context. Distributing the await is a nice idea but it seems to suggest different runtime semantics as you have already pointed out. That would introduce type based runtime behavior...

[jods4]

@aluanhaddad

it seems to suggest different runtime semantics as you have already pointed out

Not sure what you are referring to.

By 'distributing' I meant that the expression await (X | Promise<Y> | Thenable<Z>) should be valid and have type X | Y | Z.

[mhegazy]

Given that Promises are built-in type and well defined in the spec. changing what it means seems like an advanced option, and would be out of scope for the time being.