Constant constructor call should be legal in another constant constructor definition.

[DartBot]

This issue was originally filed by @Cat-sushi

---

The code below is illegal with the current language specification.

  class C {
    final x;
    const C(this.x);
  }

  class D {
    final C c;
    const D(x) : this.c = const C(x); // compile-time error!
  }

I understand that 'x' in 'const C(x);' is not a compile-time constant, but a potentially constant expression, and this is the reason why the constructor call 'call C(x);' is illegal.
I also understand the reason why the 'x' is potentially constant, the constantivity of 'x' is depends on the call site which calls the constructor whether with 'const' or with 'new'.

On the other hand, with my understanding, the compiler evaluates the result of constant expressions at compile-time, and the compiler can check constantivity at compile-time with call site sequence.
At the same time, in run-time context, constructors are less constrained, and the language processor can simply regard 'const' of 'const C(x);' as 'new', and can call the prepared run-time constructor.
I think the disregard of keyword 'const' and the need for the run-time constructor of the constructor call 'const C(x);' in run-time context are kind of similar to those of constant constructor definition like 'const C(this.x);' or const 'D(x)...;'.

So, regardless of discussion in issue dart-lang/sdk#392 and issue dart-lang/sdk#19558, I think constant constructor calls in another constant constructor definition should be legal.
And, I feel it is more natural.

In addition, I think this proposal is upper compatible of the current language specification.

[lrhn]

Treating "const" as "new" in some cases would probably be too confusing.

It is a problem that you can't create an object in a const constructor initializer list.

In the long run, a solution could be to make "new" optional, so you write:
  const D(x) : this.c = C(x);
and then let the implicit construction operator be new at runtime and const when used to create a const object. It beats introducing the new_or_const operator :)

---

Added Area-Language, Triaged labels.

[DartBot]

This comment was originally written by @Cat-sushi

---

Yes, treating "const" as "new" is confusing.

The villain of the confusion is newable constant constructor.
So, hiding keyword "const" or "new" doesn't alleviate the confusion, even aggravates it.

Of course, newable const constructor is useful and kind of reasonable.

[DartBot]

This comment was originally written by @Cat-sushi

---

In addition, on the other hand, my proposal is completely consistent in compile-time constant context, like other initialization list.

I think, it is kind of reasonable.

// 'call C(x);' in my original post is typo of 'const C(x);'. (^_^)

[DartBot]

This comment was originally written by @Cat-sushi

---

I think the current implementation compiles constant constructor without call site sequence.
Is it true? And why?
Is it related to start up speed?

I think it is the bottle neck of solution of ambiguity in potentially constant expression.
And constant constructor should be compiled with every call site.

[yjbanov]

Added Customer-Flutter label. I'd like to be able to define const convenience constructors that forward properties to a nested object.

Example:

class Semantics extends StatelessWidget {
  // This is not supported today:
  const Semantics({
    bool checked: false,
    bool selected: false,
  }) : properties = const SemanticsProperties(
    checked: checked,
    selected: selected,
  );

  const Semantics.fromProperties(this.properties);

  final SemanticsProperties properties;
}

[Hixie]

FWIW, this is forcing Flutter to have a breaking API change.

[Cat-sushi]

I think it can be closed with dart 2.0.
Thank you.
DartPad

[yjbanov]

@Cat-sushi I'm still seeing the following analyzer error: "Initializer expressions in constant constructors must be constants."

[Cat-sushi]

@yjbanov So am I.
DartPad some time emit no error, or executes it with same error.
DartVM always throw runtime exception "Not a constant expression".

[eernstg]

I also see the error in DartPad and with dartanalyzer and the vm, but this is indeed the behavior that we should have.

Constant expressions in Dart were designed to be significantly less expressive than regular Dart. In particular, there's no notion of value directed recursion (which would allow for constant expression evaluation with high complexity, e.g., like the Ackermann function). A simple example would be the following:

class A {
  final A next;
  const A(int i): next = i > 0 ? const A(i - 1) : null;
}

As mentioned in earlier comments on this issue, we might be able to omit const and have it inferred based on the invocation of the constructor, and we might also allow it and just say that this particular constructor cannot be invoked except as part of a constant expression. That's not difficult to sort out.

But if we were to support this kind of recursion then there's basically no limit on the amount of computation that any given constant expression could give rise to, and that might well cause a perceived startup time optimization to turn into a program size nightmare (if we'd compute some huge object graphs at compile-time and make them part of the shipped program).

So the rules were kept simple: For a 'constant expression' there is a tight relationship between the syntax and the semantics (one syntactic expression corresponds to one constant object at run-time, and, by canonicalization, one constant object corresponds to all the syntactic expressions that have "the same value"). For a 'potentially constant expression' Dart only allows certain built-in operations (like a + b where a and/or b are arguments of the enclosing constructor: this must be a numeric addition or a string concatenation, not a user-defined operator +).

Even C++, whose template feature is known to be Turing complete, has a notion of constant expression evaluation (constexpr) that may or may not be Turing complete, so Dart is not the only language to hesitate in this area, even though C++ is definitely going further.

In summary, there are reasons why a constructor like const D(x) : this.c = const C(x) is not supported.

This issue should not be closed based on the updates in Dart 2 (Dart 2 doesn't differ from Dart 1 in any way that makes a difference for this issue). It could be maintained as a request for some enhancement in the area of constant expression evaluation, or it could be closed because such enhancements are not trivial to introduce (nor is it guaranteed that they have widespread support).

I basically think that the situation is unchanged, and if you, @Cat-sushi, or anyone, wish to maintain the pressure to get some enhancements in this area then this issue is a fine place to have that discussion.

[yjbanov]

@eernstg thanks for explaining the background. I understand that there're a lot of cases where this could get nasty if implemented carelessly. However, I also think that there're a lot of valuable features that would be in the safe zone if we think carefully about it.

[eernstg]

I just checked whether I could find a "canonical" issue on enhancements to constant expression features, but it seems like there is no such thing. We have other requests like dart-lang/sdk#29277 about functions that could be invoked during constant expression evaluation (so that's related, but much more radical).

I think it will be difficult to extend the expressive power of constant expressions without letting it explode into something which is essentially the whole language, but it could still be worthwhile to look for simple restrictions that would be strong enough to avoid that, and still useful in common, concrete scenarios.

[yjbanov]

There's also my ancient DEP: https://github.com/yjbanov/dart-const-functions