can't assert "== null" in an initializer assert (but != null works)

[Hixie]

class A {
  const A(this.a, this.b) : assert(a == null || b == null);
  final Object a;
  final Object b;
}

...results in:

  error • In constant expressions, operands of this operator must be of type 'bool', 'num', 'String' or 'null' at test.dart:2:36 • const_eval_type_bool_num_string
  error • In constant expressions, operands of this operator must be of type 'bool', 'num', 'String' or 'null' at test.dart:2:49 • const_eval_type_bool_num_string

...but this works fine:

class A {
  const A(this.a, this.b) : assert(!((a != null) && (b != null)));
  final Object a;
  final Object b;
}

[a-siva]

Are you using the --assert_initializer option. I tried this on TOT command line dart VM and it seems to work :
class A {
const A(this.a, this.b) : assert(a == null || b == null);
final Object a;
final Object b;
}

main()
{
A a = new A(null, null);
print(a);
}

sivalinuxmach[sdk]>out/ReleaseX64/dart --checked --assert_initializer /tmp/junk.dart
Instance of 'A'

[Hixie]

Sorry, I should have been explicit. This is an analyzer failure, not a VM failure.

[a-siva]

Thanks somebody marked it under area-vm, will change accordingly.

[bwilkerson]

@lrhn I have a question about the specification, and I'm hoping you can answer it.

In section 16.1 it says:

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.

Given the code above, I would expect analyzer to figure out that a has type Object and to create an error. It looks to me like the bug is that we're not generating an error in the != case.

Is that your interpretation, or am I wrong here?

[lrhn]

Constant evaluation is all about objects, not static types. That's why the VM has been able to implement it without having a static type system.

The potentially constant vs actually compile-time constant distinction is a little tricky in the spec.

The expression a == null is a valid potentially constant expression because it would be a valid compile-time constant expression if a was a constant variable with a value that was an int, bool or string (section 10.6.3). That requirement is a static syntactic constraint on the potentially constant expression, it's independent of the value that the variable will have when the constructor is invoked -
because that can vary anyway.

When you do evaluate the const constructor call, you evaluate the expression as a compile-time constant expression as if the parameters were const variables with the provided values.
In this case, a and b both evaluate to the value null, so the equality expressions are valid compile-time constant expressions by the rule you quoted (all operands are null).

So, it's a valid potentially constant expression and evaluation as compile-time constant expression succeeds. It would succeed no matter which arguments were passed.

It would not succeed if the arguments were non-int/string/bool/null values, because then the expression a == null would not be compile-time constant, because of 16.1.

To get around that, you can use identical(a, null) instead because that's a valid compile-time constant expression for all constant values of a (the point before == in section 16.1).

(And yes, the != case should be equivalent to the == case).

[eernstg]

PS: As of f11f2ed, the spec has been modified to lift the non-int/string/bool/null restriction. Here's the updated constant expression case:

\item An expression of one of the forms  \code{$e_1$ == $e_2$} or  \code{$e_1$ != $e_2$}
where $e_1$ and $e_2$ are constant expressions, and either both evaluate to a numeric,
string or boolean value, or at least one of $e_1$ or $e_2$ evaluates to \NULL{}.

So the tools should allow it, plain == as well as !=.

[Hixie]

See also #29278 which is about allowing enums in these expressions.

[dnfield]

Tooling is allowing identical but not == e.g.

Fails:

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

Passes:

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

[eernstg]

Apparently, the implementation of this feature 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.