The expressions in the field-initializers of a const constructor must be constant expressions

[ghost]

co19/src/LangGuideTest/02_Language_Constructs/02_1_Class/02_1_Class_Const_Expressions/02_1_Class_Const_Expressions_A04_t01.dart.

[DartBot]

This comment was originally written by @mhausner

---

This isn't as easy to fix as I first thought. Looking into this I also found a gap in the language spec.

The test code looks like this:

class F {
  F() {}
  static F makeF() {return new F();}
}

class C {
  const C() : v = F.makeF();
  final v;
}

The initializer for v is clearly not a const expression, so that is easy to find and flag.

But consider this code:

class A {
  final x;
  const A(var p) : x = p * 10;
}

It is impossible to determine whether the initializer for x is a compile time constant when compiling the constructor A(). It depends on the (type of the) actual value for p at the call site whether p * 10 is a compile time const.

var a = const A(5); // ok
var b = const A("oh boy"); // not ok

According to the current language spec, p * 10 is not a compile time constant. But for practical reasons, we probably want to allow this sort of expression. In fact, our core library currently has such expressions, e.g. in the constructor of DurationImplementation.

  const DurationImplementation([int days = 0, .... ])
     : inMilliseconds = days * Duration.MILLISECONDS_PER_DAY + .... ;

(Note that the type annotation for parameter days must not be used to determine the constness of the initializer expression.)

To fix this bug,

1. the spec needs to be updated (Gilad will do this)
2. The VM needs to considerably complicate the analysis of constness of an expression.

---

Added Accepted label.

[DartBot]

This comment was originally written by @mhausner

---

Update: the spec has been updated and introduces the concept of "potentially constant expressions". The implementation of this is quite involved, though. It takes more than one rainy Sunday afternoon to implement this.

[iposva-google]

Added AssumedStale label.

[DartBot]

This comment was originally written by @mhausner

---

This is not stale, unfortunately. The VM still needs to implement the concept of 'potentially constant expression'.

---

Added Accepted label.

[iposva-google]

Removed Priority-Medium label.
Added Priority-Unassigned label.

[ghost]

Set owner to @sgmitrovic.

[DartBot]

This comment was originally written by @mhausner

---

Issue #11206 has been merged into this issue.

---

cc @sgmitrovic.

[ghost]

Missing piece: must check that only legal operations are allowed in the initializer.

---

Set owner to @mhausner.

[iposva-google]

Issue #11624 has been merged into this issue.

[iposva-google]

Removed Priority-Unassigned label.
Added Priority-Medium label.

[DartBot]

This comment was originally written by @mhausner

---

r24749 adds another check to detect initializer expressions that are known not to be constant. We still don't detect all cases where initializers are not const. For example, a user-defined class that implements arithmetic operators and returns a number is not a compile-time const but is not detected to be illegal.

[iposva-google]

Issue #811 has been merged into this issue.

[lrhn]

This example of a related problem came up on the mailing list:

typedef String EchoType(String arg);

class Echo {

  final EchoType echo;

  const Echo() : echo = simpleEcho; 

  const Echo.verbose() : echo = verboseEcho;

}

String simpleEcho(String arg) => arg;

String verboseEcho(String arg) => "arg: $arg";

void main() {
  print(const Echo().echo("test"));
}

Fails with:

'file:///home/luiz/dev/testDart/bin/test.dart': error: line 19 pos 21: Invalid const object field: Closure: (String) => String from Function 'simpleEcho': static.

  print(const Echo().echo("test"));

According to mhausner:
The problem here is that we compile the constructor Echo() only once, but in can be invoked in two different ways: const Echo() and new Echo(). The first requires the initializer expressions to be compile time constants and canonicalized, the second does not. The compiler only generates the version for new Echo() and thus does not canonicalize the closure 'simpleEcho'.

---

Edit:
This explanation doesn't explain everything - the simpleEcho closure should be a compile-time constant in all cases, whether the constructor is called as const or new.

[DartBot]

This comment was originally written by @mhausner

---

Issue #19558 has been merged into this issue.

[zanderso]

@mhausner Is this issue stale?

[mhausner]

Not yet. When we switch to the new front-end, this bug will be obsolete. We have done many partial fixes over the years but the bug has never been solved in general.