Allow statically known class fields to be used in switch statements about language

[mateusfccp]

If you make foo and bar constants, you will have what you want.

A final value is not constant, and it can be changed, although it can't be reassigned. This is why the compiler can't generally assume the value.

In your specific case maybe it could, as we have a final field of a private class, so we know it's never overriden with another getter or something like this. But it's easier for you to make it const than we deal with such specific cases.

[yakagami]

@mateusfccp my _Item class has functions and nullable fields though. It looks like this:

final class _Item{
  final String value;
  final Function fn;
  String? content;
  _BackupItem({required this.value, required this.fn});
}

I don't think I can make this const, right? That's why I'd like the compiler to realize that my single field is const. It has no problem realizing that something like

final x = 10;

is constant and lets me use it in a switch statement.

But it's easier for you to make it const than we deal with such specific cases.

Is the logic for recognizing const fields not already there? Wouldn't that be useful in any case for optimization purposes like constant propagation etc? I'd like to understand what the factors are when thinking about a feature like this.

[lrhn]

Switch cases must be constant, because the compiler needs to know the values to determine if the switch is exhaustive.
Even for switches that don't have to be exhaustive, the value needs to be constant so that the compiler can optimize the switch based on known value. A non-constant value isn't known to the compiler. The foo.value is not constant because the object referenced by foo doesn't exist yet at compile-time. It may never exist, it's only created the first time the foo variable is read.
So it isn't "statically known" at all.

Also, even if the foo object could be made to be known at compile-time, somehow, then its value getter cannot be assumed to be stable. Reading it more than once must be assumed to be able to give different values.
It can't in the current program, but the _Item class doesn't promise to not change value to a getter in a later version. If a switch can assume that the variable is stable, then it becomes a breaking change to change it to a getter, something that's not breaking today.

In very, very many cases where it looks "obvious" that a program has some statically determinable property, and the compiler doesn't use that, it's because using that property for anything makes it breaking to change the code. Any time the compiler assumes, fx, that a final field is stable, it becomes breaking to change that final field to a getter. Even if the author never intended or promised that the variable would be stable, or that its value could be known at compile-time.
That's why the compiler requires you to write const in front of constant variables, even if it's "obvious" that the value is constant. It might not be the author's intent, it's just an accident of implementation, and if the compiler changes behavior based on something the author hasn't promised, it makes more things breaking changes.

[yakagami]

@lrhn Thanks for the insightful reply. I appreciate that you took the time to explain that.