Typescript: Compiler suggestion: explicitly await

[Roam-Cooper]

I'm not incredibly familiar with the compiler's internals, so if someone wants to rewrite this suggestion as a proposal, go ahead!

I've noticed it is quite easy for a developer to call an async function/method without awaiting on it, so it would be nice to have a compiler option similar to noimplicitany;noimplicitreturns; etc, where a developer has to explicitly declare that they wish to call an async function/method without awaiting on it.

This would help keep developers aware that the function/method is asynchronous so that they don't accidentally call it without awaiting on it.

[yortus]

There are many valid things to do with an async function other than awaiting it. It's just a function that returns a promise, after all. So you may want to explicitly assign that promise to a variable or push it into an array and then use Promise.all, etc.

Perhaps rather than looking for an explicit await, it would be better to just flag cases where the return value of the async function call has not been used at all. Such calls often do indicate a potential error, where the programmer expects the function call to complete before the next statement executes.

[nippur72]

With type annotations the error is easily spotted, e.g. the compiler will warn if you are trying to use a Promise<number> instead of a number. But still it can be useful if the compiler emits a dedicated warning/error. Perhaps a rule for tslint ?

[RyanCavanaugh]

The problem is that, as noted, there are an infinite number of valid ways to "correctly" handle a Promise (and people will have varying definitions of "correct", including those who _want_ to conditionally not await something ever!). If you want to enforce in your project that you only handle them in a finite set of allowed ways, that's a good candidate for a TSLint rule.

[nippur72]

looks like someone is already trying to write it: https://github.com/palantir/tslint/issues/892

[Roam-Cooper]

Oh, yes. Adding it to linting is definitely a good idea.

I just thought it might be able to be implemented as an "unused variable/value" type warning. Linting works for us, though.