Skip to content

enums should be allowed in constant expressions #29278

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Hixie opened this issue Apr 6, 2017 · 9 comments
Closed

enums should be allowed in constant expressions #29278

Hixie opened this issue Apr 6, 2017 · 9 comments
Assignees
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). core-l type-enhancement A request for a change that isn't a bug

Comments

@Hixie
Copy link
Contributor

Hixie commented Apr 6, 2017

It's common in Flutter code to use enums heavily. Since these are always entirely known at compile time, it is unfortunate that they cannot be used in constant expressions. (Constant expressions with enums would allow us to assert things about arguments based on enums in constant constructors which would allow big performance wins in widget trees which could be constant in principle but can't today because of this issue.)

enum X { a, b }
const bool foo = X.a == X.b; // <-- won't compile
void main() {
  print(foo);
}
@lrhn lrhn added area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). type-enhancement A request for a change that isn't a bug labels Apr 6, 2017
@lrhn lrhn self-assigned this Apr 6, 2017
@lrhn
Copy link
Member

lrhn commented Apr 6, 2017

I agree, we should extend == to also cover enum values.
You can use identical(X.a, X.b) until that happens.

I'm considering changing the requirement for e1 == e2 being constant to only be conditioned on the type of e1, or e2 being null, but not requiring e2 to be a number, string, bool, or enum. It's not important anyway, so it's just more work checking it.

@srawlins
Copy link
Member

Not sure when this changed, but this now works in the VM 😕 . It does not work in dart2js, and the analyzer is unhappy about it still.

@lrhn
Copy link
Member

lrhn commented Jun 29, 2018

It shouldn't work. The language specification has not been changed to allow this.
(We still should, but it hasn't happened yet).

@bergwerf
Copy link

This would also be nice for writing assert statements in a const constructor for an enum class field. I was trying to do this:

class ExprSymbol {
  final SymbolType type;
  final num value;
  final int argumentCount;

  const ExprSymbol(this.type, this.value, this.argumentCount)
      : assert(type == SymbolType.number ? argumentCount == 0 : argumentCount != null);
}

@gnudles
Copy link
Contributor

gnudles commented May 28, 2019

consider also:
enum Fruit {
apple,
banana
}
const int a = Fruit.apple.index+1;

@srawlins
Copy link
Member

I think the original request can be closed in favor of dart-lang/language#312 in the new language repo.

(That enhancement doesn't address other requests above like enum fields in const classes, or accessing an enum's index and using + in a const context.)

@mit-mit
Copy link
Member

mit-mit commented Aug 19, 2021

Closing as this is now being tracked in dart-lang/language#312

If you voted on the present issue, I'd encourage you to vote on issue 312 above in the language repo.

@mit-mit mit-mit closed this as completed Aug 19, 2021
@mshenawy22
Copy link

Enums produce an error in switch expressions Case expressions must be constant

@lrhn
Copy link
Member

lrhn commented Nov 17, 2022

Enums are constants. They also have primitive equality, so they should work in switches.

The problem here was that they did not work with == in constant expressions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). core-l type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

7 participants