Expressions of type void should be allowed in switch expressions

[munificent]

The language has some fairly ad hoc rules about where expressions of type void are and aren't allowed. The patterns specification makes no mention of disallowing expressions of type void anywhere so I assumed that, by default, they would be allowed. However:

void printBugsSwitch(int n) => switch (n) {
      0 => print('no bugs'),
      1 => print('one bug'),
      _ => print('$n bugs'),
    };

void printBugsConditional(int n) => n == 0
    ? print('no bugs')
    : n == 1
        ? print('one bug')
        : print('$n bugs');

Currently, this produces on analyzer:

Analyzing temp.dart...                 0.5s

  error • temp.dart:2:12 • This expression has a type of 'void' so its value can't be used. Try checking to see if
          you're using the correct API; there might be a function or call that returns void you didn't expect. Also check type
          parameters and variables which might also be void. • use_of_void_result
  error • temp.dart:3:12 • This expression has a type of 'void' so its value can't be used. Try checking to see if
          you're using the correct API; there might be a function or call that returns void you didn't expect. Also check type
          parameters and variables which might also be void. • use_of_void_result
  error • temp.dart:4:12 • This expression has a type of 'void' so its value can't be used. Try checking to see if
          you're using the correct API; there might be a function or call that returns void you didn't expect. Also check type
          parameters and variables which might also be void. • use_of_void_result

And if you try to run it:

temp.dart:2:12: Error: This expression has type 'void' and can't be used.
      0 => print('no bugs'),
           ^
temp.dart:3:12: Error: This expression has type 'void' and can't be used.
      1 => print('one bug'),
           ^
temp.dart:4:12: Error: This expression has type 'void' and can't be used.
      _ => print('$n bugs'),
           ^

Note that there are no errors in printBugsConditional(), which has similar behavior using conditional expressions. I think switch expressions should behave similarly to conditional expressions.

I'm going to put this in the stable milestone so that triaging folks take a look at it. This is an annoying restriction (at least two users have already noticed it), but I don't know if it's worth trying to cherry pick a fix for it. Since fixing this bug is removing a restriction, it's a non-breaking change that we could do in 3.0.1 or 3.1 if needed. Personally, I would lean towards not trying to cherry pick a fix, but I'm happy to defer to implementers (who know how hard/risky this is to fix) and leads (who know how much risk we want to accept).

Related language issue: dart-lang/language#2907

cc @dart-lang/language-team

[munificent]

cc @johnniwinther @scheglov

[johnniwinther]

I'll take a look at the CFE side of this.

[mit-mit]

Is this different from dart-lang/language#2907 ?

[lrhn]

Yes. Or it's a subset, but not the most important subset.

dart-lang/language#2907 mentions expression in new syntactic locations, like:

• The switch expression itself (switch (<here>) ...), for the new expression switch.
• The pattern constants values case <here>, case const (<here>), case == <here>.

These are new syntactic locations for expressions where the value is pretty certainly used, so they should likely not be allowed to be expressions with static type void.

It didn't mention the expression switch case result expressions, which it probably should, but they are still within our current framework, we just need to say "yes" to those, like we usually do for expressions in tail position (the value of this expression becomes the value of the surrounding expression, without anyone looking at the value on the way).

The current void-prevention scheme is about which expression positions are allowed to have type void.
Then dart-lang/language#2907 points to another issue, where a value is produced by something which is not an expression like case Foo(bar: var x) where Foo.bar has static type void, but matchedValue.bar is not an expression anywhere in that program.

We don't have an existing framework to put that into, so that's the real meat of the issue.
We'll need to introduce rules for when a matched value type is allowed to be void.
(Suggested answer, only for non-checking, non-binding patterns like _).

[scheglov]

https://dart-review.googlesource.com/c/sdk/+/299200

[scheglov]

https://dart-review.googlesource.com/c/sdk/+/299200 landed.

[munificent]

I consider #270 to be the issue to discuss whether we want to change the specification of which expression contexts related to patterns allow void.

I filed this issue to track the fact that the implementations currently disallow void expressions in a context where the spec doesn't forbid it.

[johnniwinther]

CFE fix landed in https://dart-review.googlesource.com/c/sdk/+/299020

[scheglov]

CP request for the analyzer.
#52218

[leafpetersen]

I'll prepare a CP request for the CFE fix. Note that we have decided to push the cherry pick to the first hot fix release, since the fix will be non-breaking to land.