Repository navigation
Compiler suggestion: explicitly await #10381
Description
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.
Activity
yortus commentedon Aug 17, 2016
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 commentedon Aug 17, 2016
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 anumber. But still it can be useful if the compiler emits a dedicated warning/error. Perhaps a rule for tslint ?RyanCavanaugh commentedon Aug 17, 2016
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 commentedon Aug 17, 2016
looks like someone is already trying to write it: palantir/tslint#892
Roam-Cooper commentedon Aug 18, 2016
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.