New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
stereotype441 opened this Issue Dec 5, 2017 · 2 comments

Comments

@stereotype441
Member

stereotype441 commented Dec 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@eernstg

eernstg Dec 6, 2017

Member

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?". ;-)

Member

eernstg commented Dec 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kmillikin

kmillikin Dec 14, 2017

Member

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).
Member

kmillikin commented Dec 14, 2017

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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment