unawaited_futures linter rule does not trigger in switch statements

[mrudigier]

We are using the flutter_lint package in our project. Recently we noticed, that, when we have mixed Future and sync return values in a switch statement, dart "sets" the return value as sync. However, the futures are then not marked as "unawaited" by the linter rule, as expected.

• Turn on the unawaited_futures rule
• Create a Method with a Future return type, which returns the result of a switch statement (=> notation).
• Make it so, that at least one case points to a Future, and one not.

Expected results

It is expected, that the Future in the switch statement triggers the unawaited_futures linter rule. I guess it is implicitly unawaited by the switch. This is a potential bug, and the linter rule can help to identify it.

Actual results

The linter does not mark the future as unawaited.

I have posted this as a flutter issue first ( flutter/flutter#161752 ), but it is probably better situated here.

Sample code to illustrate the issue:

class Test {
  void doSomethingSync() {}

  Future<void> doSomethingAsync() async {
    Future<void>.value(); // linter rule unawaited_futures is triggered by this
  }

  void onlySyncSwitch(TestOption option) {
    final result = switch (option) {
      TestOption.optionA => doSomethingSync(),
      TestOption.optionB => doSomethingSync(),
    };
    return result; // result is void
  }

  Future<void> onlyAsyncSwitch(TestOption option) {
    final result = switch (option) {
      TestOption.optionA => doSomethingAsync(),
      TestOption.optionB => doSomethingAsync(),
    };
    return result; // result is Future<void>
  }

  Future<void> mixedSyncAndAsyncSwitch(TestOption option) async {
    final result = switch (option) {
      TestOption.optionA => doSomethingSync(),
      TestOption.optionB =>
        doSomethingAsync(), // expect that unawaited_futures triggers, but it does not.
    };
    return result; // result is void
  }
}

enum TestOption {
  optionA,
  optionB,
}

[FMorschel]

Initial notes unrelated to resolution

1. When you add a code block using backticks like this you can add "dart" after the three opening ones so it knows how to place colouring
2. It is actually a switch expression in this case (when it returns something - or uses the => notation as you said)

Problems only can happen to the code in question because your result is void typed. If you had something like #55337 this could maybe work. But if you remove the assignment to result (useless in this case since it is void) and add a return directly, I'd expect it all to work fine and still not trigger the lint.

Future<void> bar(int value) async {
  final test = baz();
  baz();
}

Future<int> baz() async => 1;

The unawaited_futures doesn't trigger if you assign it to a variable since in that case the variable has the Future type and you can handle it from there.

[mrudigier]

Thanks for the quick reply. I'm not sure if I understand completely.

The example might not be ideal. I only added the "result" as an in-between step in order to highlight, that the switch return value is void and not Future<void>, as in the case where all switch expressions are futures.

The return type of mixedSyncAndAsyncSwitch is not FutureOr, it might be that it works correctly in that case. We came across the issue in a case like mixedSyncAndAsyncSwitch, where we noticed that we cannot await whatever is returned by the switch if the expressions are mixed (it works if the are not mixed).

[FMorschel]

As I understand, when a Function returns Future and is async it can return either a Future of that type or that type directly. Please @lrhn can you confirm this and help me explain?

[mrudigier]

Ah, I think I see my misunderstanding. The async takes care of it, so it all works as intended. And the method cannot be without async, because then the return value is not correct.

My interpretation was, that there was somehow an implied unawaited there.

[lrhn]

More like an implicit await.
The return of an async function should check whether you're returning a future or a non-future, and await the future before returning its value.

I hope to one day get rid of that, but it's hard.

I'm slightly worried that we allow return voidTypefExpression; in a position where we'll then check whether that value is actually a Future<void>.
Probably unavoidable for now.

[srawlins]

I think this request goes against the design of unawaited_futures and discarded_futures. If a Future-typed expression is assigned to a value, or passed as a function argument, etc, it is considered "handled."