Confusing error message when a `void` value is used

[sgrekhov]

FutureOr<void> foo() => print(""); // print() returns void

The code above produces an error in both analyzer and VM. Analyzer error message is A value of type 'void' can't be returned from the function 'foo' because it has a return type of 'FutureOr<void>' and VM error is Error: A value of type 'void' can't be returned from a function with return type 'FutureOr<void>'.

This error message is confusing. void is assignable to FutureOr<void>, the problem here is that a void value returned by print() is used. Please update the error message accordingly.

cc @eernstg

Dart SDK version: 3.7.0-71.0.dev (dev) (Fri Oct 25 17:06:43 2024 -0700) on "windows_x64"

[dart-github-bot]

Summary: The error message "A value of type 'void' can't be returned from the function 'foo' because it has a return type of 'FutureOr'." is confusing because void is assignable to FutureOr<void>. The actual issue is that the void value returned by print() is being used, not the type itself. The error message should be updated to reflect this.

[eernstg]

Right. I adjusted the labels to indicate that this is concerned with the diagnostics from both tools. I removed type-bug because i think improve-diagnostics is usually specified alone, and it is taken to imply some kind of a type-bug treatment.

The error message sounds like there was a subtype test void <: FutureOr<void>, and it failed (so we can't return that value because it isn't type correct). However, as @sgrekhov mentions, that subtype relation does hold.

The actual reason why there is an error is that the allowlist for using the result from evaluation of an expression of type void (https://github.com/dart-lang/language/blob/9dc3737010f3ccac5ef54bf63b402d8e86b9115c/specification/dartLangSpec.tex#L22666) doesn't contain any items that match return print("");.

So I'd expect an error message saying something like "This expression has a type of 'void' so its value can't be used" or "This expression has type 'void' and can't be used".

[abitofevrything]

So I'd expect an error message saying something like "This expression has a type of 'void' so its value can't be used" or "This expression has type 'void' and can't be used".

Wouldn't that imply that the following code should also be an error?

void foo() => print("");

Because that is currently valid code, and I expect it to work.

In what way is changing the return type to FutureOr<void> making it so that the error appears?

It also seems weird that this code does work, if this is working as intended:

FutureOr<void> foo() async => print("");

[Wdestroier]

Can the implementation or specification be fixed? It should work. I asked Gemini 2.5 Pro and it agrees:

User:
Will this code work in Dart?

`FutureOr<void> foo() => print(""); // print() returns void`

Agent:
Yes, that code will work perfectly fine in Dart.

...

Since print("") returns void, and void is one of the valid types for a function declared to return FutureOr<void>, the code is type-safe and will compile and run without issues.
In summary: Your function foo() synchronously executes print("") and implicitly returns void, which satisfies the FutureOr<void> return type.

[bwilkerson]

So I'd expect an error message saying something like "This expression has a type of 'void' so its value can't be used" or "This expression has type 'void' and can't be used".

Would we want the same message when using an explicit return (as below), or is the current message better in that situation?

import 'dart:async';

FutureOr<void> foo() {
  return print("");
}

If the current message would be better for the case above, then perhaps we should simply enhance the current message in order to help build the correspondence in the user's mind. Perhaps something like "A value of type 'void' can't be implicitly returned from a function with return type 'FutureOr'.".

[abitofevrything]

I feel like the spec should be updated when it declares arrow function bodies to be a compile time error if

The function is synchronous, T is not void, and it would have been a
compile-time error to declare the function with the body { return e;
} rather than => e.

As this excludes functions returning FutureOr<void>, despite it being intuitive that they would work the same as functions returning void in this aspect.