[Analyzer] evaluation of const expression fails when List.length is used in assertion

[dnfield]

class ColorFilter {
  const ColorFilter.matrix(this.matrix)
      : assert(matrix != null),
        assert(matrix.length == 20);

  final List<double> matrix;
}

const ColorFilter sepia = ColorFilter.matrix(<double>[
    0.39, 0.769, 0.189, 0, 0, //
    0.349, 0.686, 0.168, 0, 0, //
    0.272, 0.534, 0.131, 0, 0, //
    0, 0, 0, 1, 0, //
  ]);

void main() {
  print(sepia.matrix); 
}

As far as I can tell this should just work (it works at runtime in the VM), but it's failing the analyzer.

/cc @stereotype441 @pq

[dnfield]

Removing the assertion on matrix.length makes the analysis error go away.

[dnfield]

Looks like this wouldn't compile in dart2js either... At least for dartpad, it complains that the value isn't a string.

[dnfield]

Error compiling to JavaScript:
main.dart:10:39:
Error: `const <double>[0.39, 0.769, 0.189, 0.0, 0.0, 0.349, 0.686, 0.168, 0.0, 0.0, 0.272, 0.534, 0.131, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0]` of type 'List<double>' is not a valid operand for a .length expression. Must be a value of type 'String'.
const ColorFilter sepia = ColorFilter.matrix(<double>[
                                      ^
Error: Compilation failed.

[eernstg]

You cannot get the length of a list in a constant expression. The language specification says so here:

\item An expression of the form \code{$e$.length} is potentially constant
  if $e$ is a potentially constant expression.
  It is further constant if $e$ is a constant expression that
  evaluates to an instance of \code{String}.

So it must be rejected at compile-time. This is one of many situations where it's tempting to make Dart constant expressions just a little bit more expressive, but it is quite costly (in so many ways) so it's not very likely to happen. One issue is that you can write a class MyList extends List<String> {...} and make the length getter run arbitrary code, and still have a const constructor in MyList, and constant expressions will not run arbitrary code, so you'd need to find the right borderline between the lists where .length is OK and the lists where it isn't, and the type system wouldn't be able to prevent the latter from occurring where a List or List<T> for some T is specified.

[dnfield]

In my example, isn't the <double>[] constant? Shouldn't that fall into the case where it's potentially constant and be allowed?

[dnfield]

Ahh I see, if I did it for some other arbitrary type it would fail.

So is the bug that the VM compiler allows this?

[vsmenon]

I believe the bug here is that the front-end is not rejecting this at compile time.

[vsmenon]

Here's the existing bug:

#35420

Closing this in favor of that.