Suggestion: Implied Promise return type in async functions

[nevir]

Apologies if this has already been brought up, but I wasn't able to find any issues that cover this topic (#5911 seems closest).

The Current State

Currently, if you want to enforce typing of an async function's resolved value, you must declare a return type of :Promise<ResolveType>:

async function makeStuff():Promise<Stuff> {}

This is a bit counterintuitive when it comes to async functions, as they generally mask the fact that there's a Promise there to begin with. If you are utilizing promises purely via async/await, you're never going to see the token Promise in your code.

Proposal

When providing the return type of an async function, implicitly wrap it in a Promise<T> (unless it is an explicit Promise<T> type expression?). This seems reasonable now that #6631 is in.

async function makeStuff():Stuff {}

Seems like the least surprising way of declaring an async function

[yortus]

Would you suggest doing the same for generator functions for consistency:

function* foo() { // inferred return type is `IterableIterator<number>`
    yield 1;      // change that to just `number` under this proposal?
    yield 2;
    yield 3;
}

Also, I think a case could be made for this change being equally confusing, even as you say when the Promise token appears nowhere in the source:

function foo(): string {/***/}
var s1: string = foo(); // OK

async function bar(): string {/***/}
var s2: string = bar(); // ERROR

[nevir]

Would you suggest doing the same for generator functions for consistency:

I think that would make sense; though I haven't wrapped my head around generators enough to be confident.

---

Also, I think a case could be made for this change being equally confusing, even as you say when the Promise token appears nowhere in the source:

async function bar(): string {/***/}
var s2: string = bar(); // ERROR

That's a good error to have! Lets you know that you should be awaiting bar(). Ideally the error message would hint about await, as well.

[tinganho]

I also think it is annoying to have to specify the Promise type, when it can be inferred from the async keyword already.

[ljqx]

Then how could we specify that we want to use Bluebird's Promise, not the original one?

[nevir]

Then how could we specify that we want to use Bluebird's Promise, not the original one?

As of #6631, you can't do that any more (except by providing your own __awaiter implementation)

[yortus]

I also think it is annoying to have to specify the Promise type, when it can inferred from the async keyword already.

@tinganho the whole Promise<T> return type can be inferred already without having to specify a return type annotation at all. I take it you are referring to a situation where the compiler cannot work out from the function body what is the T type in Promise<T>, so that you have to annotate it yourself? How common is this?

[tinganho]

@yortus sorry my bad, i was referring to the original proposal that Promise is not required to annotate a return type for an async function. There is an implied Promise when you use the async keyword.

[yortus]

I think a fuller example showing the pain point / motivating scenario would be useful. The OP gave this example:

async function makeStuff():Stuff {}

But it's unclear from this line why the : Stuff annotation needs to be added at all. What does the function body look like, that the compiler cannot infer the return type? Usually it can accurately infer the return type with no annotation at all.

---

And on the point of return type inference, @nevir what do you propose the language service should do with this? E.g. if in VS Code I hover over the makeStuff identifier, does it pop up function makeStuff(): Promise<Stuff> like at present, or something else?

[tinganho]

But it's unclear from this line why the : Stuff annotation needs to be added at all. What does the function body look like, that the compiler cannot infer the return type? Usually it can accurately infer the return type with no annotation at all.

It is good practice to specify the intent first and then implement the body. If you intend the type to be of some type T, then the checker enforces the function body to return that type. I believe specifying intention before implementation yields overall less buggy result.

And in this case my intention of a function is to be async and have a return type of T. But I think it is redundant to have to specify that the return type is Promise<T>, when we have already provided the async keyword.

[yortus]

It is good practice to specify the intent first and then implement the body

Interesting.... I agree with this statement but draw a rather different conclusion. I like to express my intent through clear interfaces that can be publicly shared with callers, and then provide an implementation that satisfies these interfaces without callers needing to know the implementation details.

In this light, using an async function is often an implementation detail - it's one of several possible ways to implement a function that returns a promise.

For example, I may provide some public API function that returns a 'thenable', without wanting to couple callers to the specific promise implementation, which might be bluebird for some builds and ES6 Promise for others. So I'd like my public API to look like this:

export class Foo {
    makeStuff(): Thenable<Stuff>;
}

Now I can implement this class in a variety of ways that satisfy the contract, keeping the implementation details decoupled from the public interface.

One such way would be like this:

export class Foo {
    async makeStuff(): Thenable<Stuff> {
        // make some stuff...
        // returns an ES6 Promise of stuff, which is-a Thenable<Stuff>
    }
}

Another way would be like this:

export class Foo {
    makeStuff(): Thenable<Stuff> {
        return new bluebird.Promise(...)
    }
}

Either way, the public interface remains the same.

The declaration async makeStuff(): Thenable<Stuff> would not be possible under this proposal. In fact, it's already not possible due to the already divergent treatment of async function return type annotations. I'd prefer that treatment of async function return type annotations was made more consistent with how they currently work on ordinary and generator functions, e.g. so the async function implementation in the above example works just as well as the bluebird implementation.

[tinganho]

@nevir I think your proposal misses how interface declarations should look like but I guess they should use the async keyword as well?

interface A {
    async method(): string;
}

[yortus]

How is this:

interface A {
    async method(): string;
}

different from this:

interface A {
    method(): Promise<string>;
}

Does the first one mean that the interface only matches an async function, and not an ordinary function that returns a promise? Putting async in an interface declaration adds no expressivity to the type system, but possibly introduces an artificial distinction between two kinds of promise-returning functions that are interchangeable (and for most purposes indistinguishable) at runtime.

[tinganho]

@yortus my thought was that there is no difference between them.

[DanielRosenwasser]

interface A {
    async method(): string;
}

Actually, that's not a valid signature - async isn't allowed as part of a type (since all you need to know is that there's promise returned).

[tinganho]

Actually, that's not a valid signature - async isn't allowed as part of a type

I think this proposal is to make it valid. Otherwise it is a little bit inconsistent that you can write async with implied Promise on function declarations, but not in interface declarations. Or do you mean that it is not technically possible?