avoid_void_async not working as expected

[zim32]

Describe the issue
I had a hard to detect bug, where avoid_void_async could help a lot but it did not

Here is code to reproduce:

class Test {
  void Function() callback;
  Test({required this.callback});
}

Future<void> main(List<String> arguments) async {
  Test(
    callback: () async {},
  );
}

Here I expect that I can not type async in callback parameter, because it expects void Function() instead of Future Fucntion()

This is intented behaviour or a bug?

Here is my linter rules:

linter:
  rules:
    - unawaited_futures
    - await_only_futures
    - avoid_void_async
    - void_checks

[parren-google]

Seems similar to #1123.

[srawlins]

This is not the purview of avoid_void_async. A function which is typed void Function() can be async. That lint rule discourages you from writing a return type of void for a function which is async.

I think your issue is valid though, if void-typed async functions are to be avoided. It sounds like it would warrant a new rule, that discourages you from using an async function in a context of a Future-returning function type.

[eernstg]

Note that this issue has some amount of overlap with dart-lang/language#3715, which is reporting that the inferred return type for sync*, async, and async* function literals differs from the specified value.

In particular, () async {} in the example should have an inferred return type of void because it occurs in a position where the context type is void Function(). However, it is actually inferred to have return type Future<void>.

If the static analysis is adjusted such that the inferred return type is void then the function literal should be flagged by avoid_void_async because it's a function whose body has the modifier async, and it has declared return type void.

[bwilkerson]

@scheglov For the presumed inconsistency with the specification in the second paragraph above. (Assuming that "should have" means according to the spec.)

[eernstg]

Oh, I did mean "according to the spec", but the outcome of the discussion in dart-lang/language#3715 could still be "we don't like breaking changes, so let's change the specification to match the current behavior".

Also, if the rest of the language team supports changing the behavior to be like the specified behavior then there might have to be a breaking change process.