Expand the definition of potentially constant expression.

The current definition requires the expression to be valid and
compile-time constant if constructor parameters are considered
compile-time constants with types appropriate for their context.

This is necessary but not sufficient, so this CL adds the further
requirement that the expression must also be a valid (not necessarily
constant) expession if the parameters are considered non-constant
variables.

This rules out the case:

    const C(x) : y = const [x];

where the current specification would, technically, allow it as a
potentially constant expression and therefore be a valid const
constructor. In practice it would never work if the constructor is
used with "new" instead of "const".

This is not really a specification *change* - existing implementations has this restriction anyway.

Addressed the concern of #24970.
BUG= http://dartbug.com/24970
R=eernst@google.com, gbracha@google.com

Review URL: https://codereview.chromium.org/1465473002 .
This commit is contained in:
Lasse R.H. Nielsen 2016-01-20 13:21:39 +01:00
parent 3bf3f483a5
commit 2a0cc74db1

View file

@ -1547,7 +1547,7 @@ The superinitializer that appears, explicitly or implicitly, in the initializer
Any expression that appears within the initializer list of a constant constructor must be a potentially constant expression, or a compile-time error occurs.
\LMHash{}
A {\em potentially constant expression} is an expression $e$ that would be a valid constant expression if all formal parameters of $e$'s immediately enclosing constant constructor were treated as compile-time constants that were guaranteed to evaluate to an integer, boolean or string value as required by their immediately enclosing superexpression.
A {\em potentially constant expression} is an expression $e$ that would be a valid constant expression if all formal parameters of $e$'s immediately enclosing constant constructor were treated as compile-time constants that were guaranteed to evaluate to an integer, boolean or string value as required by their immediately enclosing superexpression, <em>and</em> where $e$ is also a valid expression if all the formal parameters are treated as non-constant variables.
\commentary{
Note that a parameter that is not used in a superexpression that is restricted to certain types can be a constant of any type. For example}