Too many errors when using `const identifier` in constructor initializer

[Naomi-alt]

Not sure whether this is the right place for the issue, so tell me if I'm in the wrong place.
Version: Dart SDK version: 2.12.0-29.10.beta (beta) (Tue Nov 17 10:50:22 2020 +0100) on "linux_x64"

I have this class that I want to initialize using named parameters, and using those parameters I create the final variable in the initialization list.
But whatever I try, it doesn't seem to work. I have it narrowed down to the following example:

class Class1 {
  const Class1({this.variable});

  final int variable;
}

class Class2 {
  const Class2({
    int variable,
  }) : class1 = const Class1(variable: const variable);

  final Class1 class1;
}

But when creating the class1 I'm getting the following error:
The constructor returns type 'dynamic' that isn't of expected type 'int'.
When I remove the const however, I get this:
Invalid constant value.

What am I missing here?

[lrhn]

What you are trying to do is not possible in Dart

Dart constant object creation expressions, like const Class1(...), must create the same object every time they are evaluated.
That's one way Dart ensures that constant evaluation cannot blow up exponentially.
Because of that, you cannot use a variable of the surrounding constructor inside the const object creation expression.

The error message looks weird, though. The const variable is not a valid Dart expression at all, so it shouldn't be telling you what type it has.

[Naomi-alt]

Maybe I'm not understanding this entirely, but why does it matter where the variable comes from?
Class1(variable: variable) will always return the exact same thing given the same input right?

[eernstg]

Class1(variable: variable) will always return the exact same thing given the same input

True, but that is not sufficient. Each constant expression in a program must yield the same object every time it is evaluated (which means that we can create the object at compile-time), and "same thing given the same input" allows it to yield different objects for different inputs. (In this requirement, "the same object" takes canonicalization into account, and that basically means that it must be the same object, or it must be a new object whose fields are bound to the same objects as the fields of the previous result, and that by canonicalization makes it the same object every time.)

If we were to require only "same object given the same input" then we would expand constant expressions from being proportional to the source code into at least exponential:

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

The expressive power of constant expressions could be expanded in a myriad of ways, and it's been requested again and again, but it is very costly to do it (in terms of the complexity of the language and its implementation), so it won't happen easily.

About the error message: The analyzer error message is only emitted when const variable occurs in a library that hasn't enabled null safety. So the issue goes away then null safety is enabled; nevertheless, legacy code will be around for quite a while, so it would be helpful to address the issue.

The analyzer seems to consider variable as being the rest of a <constObjectExpression> (like C() is the rest of const C()), and then it recovers from variable not being a constructor invocation by considering it to yield an object of type dynamic. @scheglov, perhaps it would be possible to report that a constructor invocation was expected at the point where something else (like variable) was encountered?

[bwilkerson]

The analyzer produces three diagnostics for the code above:

error: The name 'variable' isn't a class. (creation_with_non_type at [test_package] lib/test.dart:10)
error: The constructor returns type 'dynamic' that isn't of expected type 'int'. (invalid_cast_new_expr at [test_package] lib/test.dart:10)
error: Expected to find '('. (expected_token at [test_package] lib/test.dart:10)

The third is from the parser and is the one that would most appropriately be converted to say that a constructor invocation was expected.

The first two are follow-on errors and it would be nice to eliminate them completely.

@jensjoha