Make `MyEnum.aValue.anInstanceVariable` constant

[polarby]

I have noticed that dart won't accept the argument of enums as const value, although both enums and their arguments are exclusively const.
This really sucks when trying to keep the class constant, but just by accessing the definitely constant argument the class won't be accepted as a constant one.

enum Foo {
  bar('The answer to life, the universe, and everything.'),
  baz('Flutter and dart are awesome.');

  const Foo(this.message);

  final String message;
}

class Bar {
  final Foo foo;

  const Bar(this.foo)
      : assert(foo == Foo.bar),
        assert(foo.message == "Only real messages"); // Will not accept message as const
}

Screenshot in Android studio

I am using:

• Dart SDK version: 2.19.0-444.4.beta
• Android Studio on MacOSX

[eernstg]

In general, a constant expression can only have the form x.y when y is length and x is a constant expression whose value (not static type, but the actual value) is a String, and the expression invokes the instance getter (for example, it can't be a receiver with static type Object and an extension method/getter named length on Object).

There have been many proposals for enhancements to the sublanguage of Dart that is constant expressions (check out https://github.com/dart-lang/language/issues?q=is%3Aopen+is%3Aissue+label%3Aenhanced-const). It is usually a rather expensive exercise to generalize constant expressions, so it needs to be a very desirable enhancement.

Hence, it is currently working as intended when the analyzer (or any Dart tool) reports that foo.message is not a constant expression.

The problem is usually that message could be overridden by a getter, and this could cause the evaluation of foo.message to run arbitrary Dart code during constant expression evaluation (that is: at compile time).

In this particular case we can actually know statically that message has not been overridden, because it is impossible to create (hence: encounter) an instance of a proper subtype of an enum type (because enum types do not have any subtypes other than the bottom types like Never, and the bottom types do not have instances). Nevertheless, it would still be a significant enhancement of the constant expression sublanguage if we were to allow getter invocations on enum values.

I'll move this issue to the language repository because it basically amounts to a request for this enhancement: Let x.y be a constant expression when x is an enum value of type E and y is a final instance variable declaration in E.

[Reprevise]

This would certainly be helpful when using switch statements with enum properties as case expressions must be consts.

Obviously there are better ways for this exact use case but this is just an example :)

enum MyProduct {
  premiumMonthly(productId: 'premium_monthly'),
  premiumYearly(productId: 'premium_yearly');

  const MyProduct({required this.productId});

  final String productId;
}

void main() {
  const String myProductId = 'premium_monthly';

  switch (myProductId) {
    case MyProduct.premiumMonthly.id: // does not compile
      print('is monthly');
      break;
    case MyProduct.premiumYearly.id: // does not compile
      print('is yearly');
      break;
  }
}

[eernstg]

@polarby, I think the title of this issue could be more focused, based on the discussion so far.

I've edited the title to emphasize the request for a new feature (make e.x a constant expression when e is a value of an enum E and x is an instance variable declared by E). Please feel free to make further adjustments if you think the new title somehow misrepresents your issue.

[lrhn]

My usual argument against allowing this particular constant expression is that it distinguishes between a variable and a getter, which prevents the author from changing a final variable to a getter in a later version of the same library.

Consider an a rewriting of the MyProduct enum to:

enum MyProduct {
  premiumMonthly('monthly'),
  premiumYearly('yearly');
  const MyProduct(this._frequency);
  final String _frequency;
  String get productId => 'premium_$_frequency';
}

That is currently a completely valid and non-breaking refactoring. The change should be completely invisible to clients of the enum declaration.

If we make final String productId; be usable as a constant, but not String get productId, then it's no longer an invisible change.

I'm OK with allowing a variable to be used as a constant, but I want the author to opt-in to it explicitly, so they know that they are signing up for changes to that being breaking. (It also increases the odds that there will be tests checking that the variable can be used as a constant, which will then fail if it's accidentally changed.)

Something like

enum MyProduct {
  premiumMonthly(productId: 'premium_monthly'),
  premiumYearly(productId: 'premium_yearly');

  const MyProduct({required this.productId});

  const String productId;
}

This class opts in to constantProduct.productId being usable as a constant expression. It's obvious and explicit, and you can't just break it.

We can allow non-enum classes to have const instance variables too, which only matters if they are non-abstract nd have a const constructor. Subclasses will then likely have to preserve the const-ness, if they can be used to create constants.

Without that, it's a hard no from me. Don't break field/getter symmetry, because "being a final variable" is a property that doesn't have to be stable over time.

Don't lock authors into restrictions without explicit opt-in. Especially restrictions that they might not be aware of, and where changing something locally can break other libraries which have relied on an invisible and easily-changed property.

[Reprevise]

@lrhn That makes sense to me, I was originally gonna propose the exact same thing. Though, I'd like a lint that suggests the change from final to const.

[rrousselGit]

I'm OK with allowing a variable to be used as a constant, but I want the author to opt-in to it explicitly, so they know that they are signing up for changes to that being breaking. (It also increases the odds that there will be tests checking that the variable can be used as a constant, which will then fail if it's accidentally changed.)

Something like

enum MyProduct {
  premiumMonthly(productId: 'premium_monthly'),
  premiumYearly(productId: 'premium_yearly');

  const MyProduct({required this.productId});

  const String productId;
}

This class opts in to constantProduct.productId being usable as a constant expression. It's obvious and explicit, and you can't just break it.

We can allow non-enum classes to have const instance variables too, which only matters if they are non-abstract nd have a const constructor. Subclasses will then likely have to preserve the const-ness, if they can be used to create constants.

Yes please!
Although the proposed syntax is a bit heavy, I really wish we had the ability to read the properties of constants on any object.

With metaprograming around the corner, I think that's pretty important.
Since metaprogramming relies on annotations, there's a certain reliance on constants. Not being able to use properties is quite restricting IMO. I've struggled a bit with this in build_runner

[daegalus]

Is there any update on getting something like this in Dart? The more I update the uuid package to take into account constants, and the desire by users of the library for things being constant, there are things I can do to make it more maitainable, but I am hindered by stuff like this where I can not have values of constant enums to be useable in constant expressions. I then have to find crazy workarounds or duplicate constant strings from within the enum into their own variables, causing unnecessary work and duplication.

[lrhn]

There is no current desire to make instance variables on constant objects be accessible as constants.
It goes against the getter/field symmetry and would make it a breaking change to change a variable to a getter (because the getter would not be constant).

Dart would need a feature to opt in to instance variables, or getters, being usable as constants, so that the author has chosen and promised that it is safe to do so. (And a way to actually make such getters be evaluable at compile time.)
Nothing like that is currently being looked at.

[daegalus]

There is no current desire to make instance variables on constant objects be accessible as constants.
It goes against the getter/field symmetry and would make it a breaking change to change a variable to a getter (because the getter would not be constant).

Dart would need a feature to opt in to instance variables, or getters, being usable as constants, so that the author has chosen and promised that it is safe to do so. (And a way to actually make such getters be evaluable at compile time.)
Nothing like that is currently being looked at.

That is unfortunate, because with the hard push on const as much as possible it makes writing clean code with enums that have values really hard. Because a constant that doesn't have constant values makes it hard to use those values in situations.

Then you have to write factory constructors with giant nested ternaries and values (which already exist in the enums but aren't const and can only be final) to get the needed result.