mirror of
https://github.com/dart-lang/sdk
synced 2024-09-05 08:24:39 +00:00
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:
parent
3bf3f483a5
commit
2a0cc74db1
|
@ -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}
|
||||
|
|
Loading…
Reference in a new issue