unawaited_futures doesn't work when method/function is not marked `async`

[zoechi]

Future<Null> sendInvitations() async { ... }

String doSomething() {
    inviteController
      ..sendInvitations() // <<<==== would expect a hint
      ..updateSearchTerm('');
}

but I don't get one.

Changing it to

Future<String> doSomething() async {

makes the lint show up.

[aemino]

The rule's description states:

Await future-returning functions inside async function bodies.

Await statements can only be used in function bodies that have been marked async.

[zoechi]

But then can still be used.
To me this limitation doesn't make any sense.
When I need to await, then I add async, otherwise I wouldn't.

[aemino]

In terms of my own code, I've rarely ever had to use then -- do you have a reason to use then rather than await? Either way, suggesting to use then on Futures seems somewhat out of the scope of this rule (it is called unawaited_futures, after all.)

[zoechi]

My point is that it shouldn't matter if async is used.
When an asyc call is made and the returned Future is ignored, the linter rule should warn.

[pq]

cc @bwilkerson

[bwilkerson]

Lints related to async behavior have been hotly discussed for a while. What everyone wants is to be told if they're making a mistake, but it's harder to statically determine whether a mistake has been made than might be expected.

Generally speaking, you don't want to create a future and then not do something when it completes. But sometimes that is an appropriate thing to do. I don't think we ever reached consensus as to the right way to allow some futures to be ignored without letting bugs go unnoticed.

I don't know what the right answer here is. We could try extending this rule to cover missing then invocations (which might be considered a breaking change by some users), or we could try writing a new rule that would cover those cases and just require that both be enabled to get full coverage. Neither seems ideal, but I can't think of any other options.

[zoechi]

A 2nd rule would be good enough for me.
I know that this rule is controversial because there valid cases where the returned future is ignored.
Devs who don't want to use // ignore: ... comments probably wont enable this rule at all.

I still have a hard time to understand why an ignored future in an async function is treated differently.
await is just syntactic sugar for then.

[bwilkerson]

I still have a hard time to understand why an ignored future in an async function is treated differently.

I don't know that there's any good reason for it. It's possible that the decision was largely political rather than technical.

[natebosch]

await is just syntactic sugar for then.

Not quite. It's then and ensuring the completion or error is accounted for in the return value of the function.

If you have a function that does not return Future but contains a Future we would never be able to escape the unawaited future lint.

Calling .then returns a new Future, which is now unawaited... Calling .whenComplete, .catchError, .timeout, similarly all return a Future which is now unawaited. Calling .asStream doesn't return a Future, but we certainly don't want to force this everywhere.

[zoechi]

I still don't see a difference between not awaited Futures in functions marked or not marked with async.
There is also no way to escape in functions marked async if a Future is not awaited.

There was a discussion that assigning the Future to var _ would be a good hint for the linter to ignore, but it seems that didn't get enough support. I find it a nice way to express the intent. that seems to work :)

[natebosch]

In a function not marked async it isn't possible to await a Future other than via return theFuture;.

I don't just mean this as "You can't use the 'await' keyword" - I mean this as "You cannot accomplish the semantics of 'await' without returning the Future or something chained from the Future".

Let's take your original example and imagine the lint showed up where you propose:

String doSomething() {
    inviteController
      ..sendInvitations() // imagine we have a lint
      ..updateSearchTerm('');
}

Now I want to fix this lint. How would I accomplish that?

String doSomething() {
  inviteController.sendInvitations().then(doSomethingElse); // Still a lint
  inviteController.updateSearchTerm('');
}

I suppose what I could do is:

Future<String> doSomething() {
  return inviteController.sendInvitations().then((_) {
    inviteController.updateSearchTerm('');
  });
}

If this is our goal I think we'd be better off with two lints, one as it exists and another that says "Don't call methods which return a Future from methods which aren't async" so we'd be forced to write the more readable (and easily linted) version with async.
I do think this second lint would have too many false positives to be useful.

[zoechi]

I don't just mean this as "You can't use the 'await' keyword" - I mean this as "You cannot accomplish the semantics of 'await' without returning the Future or something chained from the Future".

I still don't see how this makes a difference.

I made a call to a function foo that returns a Future, and the Future is not handled.
This is what this linter rule points out.

Future foo() async {
  return new Future.delayed(const Duration(sconds: 1, () => 5);
}

Future bar() async { 
  foo(); 
  doSomethingAfterFooCompleted();
}

void baz() {
  foo();
  doSomethingAfterFooCompleted();
}

bar has an ignored Future which causes doSomethingAfterFooCompleted() to run too early.
Because the linter rule warns about it, I am able to find the bug early and fix it.

baz has the same bug, but the linter doesn't help.

I can't see a reason why I should get a hint/warning in bar, but not in baz.
The only difference is, that in bar, there probably already was another async call I were aware of and therefore made it async, while in baz there wasn't a need previously to do something async and therefore it is still sync.

This is from a real issue I run into.
The code called an async function, but the developer wasn't aware that foo was async
and assumed that doSomethingAfterFooCompleted() is called after foo is done - which was a wrong assumption.
I had the linter rule enabled and expected to get notified about unhandled futures, but that didn't happen. So I looked for other causes until I found the actual bug.

In my opinion, this linter should hint about both or the rule causes more harm then benefit.

I don't care about one or two rules.
If they exist and they make sense, I enable them and have the safety net activated.
This is one decision.

[aemino]

@zoechi Thank you for providing this example; it gives some great insight into your perspective on this. Looking at the scenario you just described, perhaps it would be more apt to create a new rule that suggests marking the current function body as async when a Future is returned from a method call but not awaited?