new lint: `always_return_future_from_async `

[pq]

DO: return Future<void> from async functions as opposed to void.

---

There's been a bit of lively discussion about this already. A few culled highlights:

• there's a tension with current style guide recommendations
• an exception should be made for overrides (where overriding an async returning void with a void return type should be OK -- e.g., @natebosch's angular "ngInit case")
• motivation: in practice real bugs have been found where APIs evolved from set and forget to requiring awaits

@mehmetf @natebosch @lrhn @davidmorgan @matanlurey @dballesteros7: please feel free to chime in w/ nuances 🙏

TODO:

• [ ] flesh out description and rationale
• [ ] provide examples
• [ ] consider whether void async methods should be annotatable as @unawaited to signal that they are intended to be "fire and forget"

[bwilkerson]

As a side note, I'll suggest that we find a name that doesn't include "prefer". Perhaps something like always_return_future_from_async?

[pq]

Thanks Brian. Updated.

[a14n]

What would be the difference with avoid_void_async?

[lrhn]

I disagree with the lint in general. There is a place and reason for having void methods which do asynchronous computation. Disallowing a void/async function just forces people to do complicated workarounds. Example:

void log(String text) async {
  (await getLogger()).log(text);
}

becomes

void log(String text) {
  getLogger().then((logger) { logger.log(text); });
}

or

void log(String text) {
  () async {
    (await getLogger()).log(text); 
  }();
}

The reason to have a lint is that writing void by accident is a hard-to-detect problem. The author might have meant to return a Future<void> and forgot to write the Future<...>. This happens for other types too, but only top type are non-errors, and only void will suggest that the returned future is not handled.

If there is a way to detect some deliberate uses of void, then those should not be prohibited. There most likely isn't. A Future<void> returning async function looks exactly like a function that returns nothing.

So, if you go with the lint, it's because you consider the risk of using void/async functions too great. All async functions must visibly return a future, and all futures must be awaited, with all exceptions visibly marked in the source. That's a valid position to take. In that case I would not allow them to be used to implement a void interface method either. If anything, it's even easier to make a mistake when you didn't pick the return type yourself.