Allow statically known class fields to be used in switch statements

[yakagami]

example:

class Baz{
  static final foo = _Item(
    value: 1
  );
  static final bar = _Item(
    value: 2
  );
  
  static void test(){
    final testValue = 2; //or testValue = await getNumberFromDb() etc.
    switch(testValue){
      case foo.value: //->error: The expression of a constant pattern must be a valid constant.
        //do something
        break;
      case bar.value:
        //do something
        break;
    }
  }
}

final class _Item{
  final int value;
  _Item({required this.value,});
}

The above code fails to compile:

The expression of a constant pattern must be a valid constant.

foo.value cannot change as it is final and it is declared statically in Baz so it should be statically known, right? Is it possible to allow such fields to be used inside switch statements? How hard is it for the compiler to prove that foo.value is known statically?

[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.