How should we represent implicit downcast of a parameter default value in kernel?

[stereotype441]

The following code contains an implicit downcast of a parameter default value:

const List<Object> x = ...;
f({List<int> y: x}) {} // implicit downcast from `List<Object>` to `List<int>`.

Depending on the value of the constant x, this might or might not lead to an error. Note that due to the exisence of fromEnvironment const constructors, the front end doesn't do constant evaluation, so it can't tell whether an error should occur--detecting the error is postponed to runtime (as it is with other implicit downcasts). Currently the front end handles this by generating the following kernel representation:

static const field core::List<core::Object> x = ...;
static method f({core::List<core::int> y = self::x as{TypeError} core::List<core::int>}) → void {}

This seems undesirable, because:

• compile-time constants are not normally allowed to contain as expressions
• it seems a little strange that errors involving "constants" would not be detected until runtime
• it's not clear when the runtime error is expected to occur (should it occur at the time of the call to f? At the time of execution of any method which refers to f? When the program starts?). This makes it hard to write effective tests for this scenario.

[eernstg]

Conceptually, it seems reasonable to expect that the use of x as a default value would be accepted or rejected (depending on the actual value) at compile time. But that notion is a bit blurred: There's "(real) compile time" and "analysis time", and fromEnvironment is not known at analysis time.

Given that constant expressions are intended to denote compile-time constant values, and "compile time" is usually not considered different from "analysis time", couldn't we approximate the strict approach where the actual value is used by evaluating constant expressions in the front end as far as possible? (That is, reverting to the current treatment when something like fromEnvironment is encountered, and otherwise using the actual values).

I suppose this could be valuable in several ways:

• Developers could inspect compile-time constant values when they are also analysis-time constant, and hence rely on their actual value when reasoning about the program.
• Checks like the one mentioned in this issue could be performed eagerly in the typical case, and hence errors would arise "properly", during development.
• The run-time check could in any case be changed to a real compile-time check, because compilation would take place in a situation where fromEnvironment values are actually available.

So I guess the main issue would be "How much work would it take to get there?". ;-)

[kmillikin]

I think this representation is fine, and even desirable:

• Kernel constant expressions can contain whatever we decide they can (Kernel is not Dart). This should be OK.
• We should just stop using the term compile-time error and switch to static error. This is a static error.
• It's not a runtime error. It occurs whenever the back end signals static errors, which the user probably expects to be either before any code is run (AOT), or before this function is entered (JIT).