Abstract methods should not allow async modifier

[aleph-naught2tog]

This had already been discussed here which was a different issue that was concluded to be intended behaviour, but that abstract methods allowing async was not intended.

TypeScript Version: Version 3.2.0-dev.20181113

Search Terms:
abstract async, async

Code

// assuming `--lib es2015` is passed to the compiler
abstract class ShouldFailClass {
  async abstract someMethod(): Promise<number>; // This should error, but doesn't
}

Expected behavior:
Abstract methods should not allow an async modifier in the same way an interface and other type parameters don't allow them.

Actual behavior:
Abstract methods do not error with an async modifier attached; interface methods do.

Playground Link: Both of these should error, not just the second on, as discussed in the earlier linked issue. Reproduced here

Related Issues:
Originally discussed in the comments in here, where the consensus was that the behavior was intended for that case, but that async abstract should not be allowed.

[rbuckton]

@DanielRosenwasser should we also disallow async on overloads?

class C {
  async foo(); // <- should this be disallowed?
  async foo() {
  }
}

[DanielRosenwasser]

Mmm, I don't know; seems like that's okay since the following is allowed.

async function foo(): Promise<number>
async function foo() {
  return Promise.resolve(10);
}

Thoughts @RyanCavanaugh?

[Jessidhia]

There is actually a runtime difference between an async function and a function that returns a Promise.

An async function will return a rejected promise no matter what exception happens in it, whenever such exception happens, even in very early steps such as when evaluating argument defaults. In TS parlance, it's never possible for an async function to return never. A function that returns a Promise might synchronously throw and return never.

I just don't know if this is something TS is capable of reasoning about.

[Jessidhia]

@DanielRosenwasser your example of allowed code is just how the PromiseResolve algorithm works. PromiseResolve of a Promise will just inherit that promise's state. async () => Promise.resolve(10) returns a Promise that is not === the Promise.resolve(10) you just created, but that will have the same state.

[Jessidhia]

Personally, requiring the Promise<...> around the return type of async functions is unnecessary syntactic noise. As I mentioned, it is impossible to not return a Promise from an async function -- TS could just do the clever thing and present the return value as Promise<ReturnType<the called overload>>.

They even have different prototypes (that differ in @@toStringTag value so should be representable as structural types):

But that ship sailed long before I even started learning JavaScript 😓

[rbuckton]

@Kovensky: That isn't the issue at question here. The issue is whether to disallow async on ambient methods (abstract/overload/etc.).

[Jessidhia]

It seems related to me because of the contract I just mentioned. An async function is guaranteed to never throw, only reject its Promise, while a non-async function that happens to return a Promise could throw.

I guess this is kind of a broader point about having async () => foo be itself a first class type that is a subtype of () => Promise<foo> but distinct from it. Maybe I should make an issue for that.

[trotyl]

An async function is guaranteed to never throw, only reject its Promise, while a non-async function that happens to return a Promise could throw.

@Jessidhia Your argument is actually why async should be forbid from abstract method, because the implementation of an async method doesn't need to be async, making it wrong assumption of non-throwable:

abstract class Base {
    abstract async foo(): Promise<number>
}

class Derived {
    foo(): Promise<number> {
        throw new Error()
    }
}

const base: Base = new Derived()
base.foo() // Throwable