Const constructor initializer does not infer const for nested constructor invocation

[stan-at-work]

Description

Inside a const constructor, a nested const constructor invocation passed
through a redirecting this(...) initializer is reported as:

Invalid constant value.

Adding an explicit const before the nested constructor invocation fixes the
error.

This is surprising because the surrounding constructor is declared const,
and the this(...) invocation must itself produce a constant object.

Minimal reproduction

class OrderViewPrintConfiguration {
  const OrderViewPrintConfiguration.initial();
}

class OrderViewConfiguration {
  final bool ignoreUndefinedFloorPlate;
  final OrderViewPrintConfiguration orderViewPrintConfiguration;

  const OrderViewConfiguration({
    required this.ignoreUndefinedFloorPlate,
    required this.orderViewPrintConfiguration,
  });

  const OrderViewConfiguration.initial()
      : this(
          ignoreUndefinedFloorPlate: false,
          orderViewPrintConfiguration:
              OrderViewPrintConfiguration.initial(),
        );
}

The analyzer reports:

Invalid constant value.

Workaround

Explicitly adding const fixes the error:

const OrderViewConfiguration.initial()
    : this(
        ignoreUndefinedFloorPlate: false,
        orderViewPrintConfiguration:
            const OrderViewPrintConfiguration.initial(),
      );

Expected behavior

One of the following would be preferable:

1. Treat the arguments of the redirecting this(...) invocation in a const
   constructor as a const context, allowing the nested const keyword to be
   omitted.

2. If the current behavior is intentional, produce a more specific diagnostic
   and quick-fix:

   This constructor invocation must be constant. Try adding const.

The current Invalid constant value diagnostic does not make it clear that
the nested constructor is const-capable and only requires an explicit keyword.

Actual behavior

The invocation is rejected unless const is written explicitly.

[lrhn]

The expressions of a redirecting generatice const constructor must be potentially constant expressions, and some of them (on the branches actually reached during execution) must be constant expressions during execution.

A constructor invocation is only potentially constant if it is constant, so there is no way for OrderViewPrintConfiguration.initial() to be valid without a const in front.
But then, maybe that's a mistake by the author who didn't think it would be constant, and fixing it silently will hide the error.
Maybe they use uniqueId: Object() thinking that each invocation would get a unique object, but const Object() creates only one object.
Or the code is Buffer([]), and it intends for the list to be mutable, but putting const in front/being a const context would make the [] into a const [] too, which is a very different thing.

Adding const without user agreement is something the language tries to avoid, because it can easily accidentally opt the author into something that it's a breaking change to get out of again.

It is not a constant context because not all code need to be constant. Making it one would break that.
Expressions in constant context are always executed as const. That's not true for constructor expressions, the constructor can be called both const and not, and then it can be called with values that are not const-compatible. And const constructors can be written that rely on that to contain expressions that are never constant.

(It's a tricky use-case, but one I actually exploit myself in some code, just to give better error messages. Because const invocations always execute asserts, I can have asserts that check something, and then conditional expressions checking the same thing, and I know that during constant evaluation the false branch won't be evaluated. So I can put code in there that is only potentially constant, but never actually constant, and which can then throw nice and useful errors at runtime even when asserts are not enabled. It's a hack, but it works and would break if the expressions had to be constant.)

All in all, I think this is working as intended.
It's not impossible to change, after all the affected code would be an error today, but it's risky to introduce const contexts or implicit const. Just use the fix to add the const.

[rrousselGit]

It is not a constant context because not all code need to be constant. Making it one would break that.

On a const constructor, isn't all code required to be constant? Non-constant initializers would fail.
To me an implicit const here doesn't feel much different from const Foo(Bar()) vs const Foo(const Bar())

[lrhn]

On a const constructor, isn't all code required to be constant?

No. As I said, it's required to be potentially constant. It only needs to be constant when executed af part of s constant invocation.

The code here, a constructor invocation, is required to be constant, because that's the only way it can be potentially constant.
But you have to write the const, so the language can trust that you mean it

Const contexts are only introduced in specific places, not in the middle of an expression.

[FMorschel]

Just to link a related issue:

• Loosen const requirements for asserts #4260