Analyzer incorrectly reports "In constant expressions, operands of this operator must be of type 'bool', 'num', 'String' or 'null'" for == operator with enum operand

[Hixie]

enum MyEnum { a, b }

class Test {
  const Test(MyEnum arg) : value = arg == MyEnum.a ? 0 : 1;
  final int value;
}

void main() {
  Test q = const Test(MyEnum.a);
  Test r = const Test(MyEnum.a);
  print(identical(q, r));
}

VM prints "true", showing that the const expression is fine.

Analyzer says:

[error] In constant expressions, operands of this operator must be of type 'bool', 'num', 'String' or 'null' (test.dart, line 4, col 36)

[bwilkerson]

Or showing that the VM has a bug :-)

The language spec says that a constant expression can be (among other things):

An expression of one of the forms e1 == e2 or e1 != e2 where e1 and e2 are constant expressions that evaluate to a numeric, string or boolean value or to null.

It doesn't whitelist enum values. Actually, it doesn't allow enum constants anywhere in constant expressions. I'm guessing this was an oversight.

[Hixie]

I think if there's a bug, it's in the spec and the analyzer, not in the VM. :-)

[lrhn]

We could allow any compile-time constant value of a class that doesn't override Object.== as the left-hand side of a constant == operation, but that's probably a little too clever to be actually useful (that would make it a breaking change to add operator== to a class with a const constructor, which it isn't now).

Allowing enums is probably fine and useful.

(The spec, by definition, cannot have bugs - only "features" :)

[dnfield]

It seems like the following should be possible (or at least it seems to make sense), but it is not as a result of this:

class Test2 {
  const Test2({this.opt1, this.opt2}) : assert(opt1 == null || opt2 == null);
  final Object opt1;
  final Object opt2;
}

The goal being to have a const constructor where only one of two parameters is ever specified.

[dnfield]

After reading #30288 (comment) - it seems like I just need to use identical instead of == and it's all fine. While that makes some sense, it seems like it should be possible to interpret opt1 == null as being identical to identical(opt1, null) (or at least hint the user that that would work here).

[eernstg]

Apparently, the implementation of the added support for comparison with null in constant expressions was never requested explicitly. I just created #33408 to make that happen. I'm closing this because the 'area-language' part was resolved already in Oct 2017 with commit f11f2ed.