Expand the definition of potentially constant expression.

docs/language/dartLangSpec.tex

Index: docs/language/dartLangSpec.tex
diff --git a/docs/language/dartLangSpec.tex b/docs/language/dartLangSpec.tex
index 3850f200dfcfc00dea26f2a7b80fdf71a2c7f3a8..fb935f5c590c79bd8918b3040a8a2890b87cc267 100644
--- a/docs/language/dartLangSpec.tex
+++ b/docs/language/dartLangSpec.tex
@@ -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.

[eernst, 2015/11/20 10:03:18]

So, basically, you're saying that (1) is more important than (2), where

  (1) it is possible to use `new` with a `const` constructor
  (2) `const` constructors can create `const` values in field initializers and
superinitializers using arguments

If we have (2) then (1) does not always hold, and if we insist that (1) must
always hold then (2) must be prevented (which is what your added words will
achieve).

An alternative that should be considered is to have (1) in all the cases where
(2) hasn't been applied. This would, presumably, be achieved by leaving the
words in this paragraph unchanged (and maybe adding commentary to explain the
situation). This would be rather pragmatic, and it would allow for more
programs, some of which would presumably make sense. ;-)

On the other hand, the more strict approach that you propose would emphasize the
separation of interface and implementation, because it avoids the situation
where an initializer determines whether or not a given application of the
declared entity (the constructor) is admissible.

In practice, it would be an unpleasant surprise if a propagating change of
`const` to `new` suddenly stops because a certain constructor does not admit
`new`. I'm not sure whether this is worse than the converse (which is very
well-known): A propagating change from `new` to `const` is very likely to fail,
because there is no suitable `const` constructor in one of the expressions where
you wish to make that change.

Yet another option would be to say that `const`ness is a first class concept,
and some `as_const_as_the_outermost_expression` keyword could be used to specify
that nested expression which should be `const` when used in a `const` object
creation, and `new` otherwise.

[Lasse Reichstein Nielsen, 2015/11/20 10:37:55]

I'm saying that (1) is what we have been implementing so far, and what the
specification says, and (2) has never worked or been expected to work - except
for string interpolations which can satisfy both, but which the VM doesn't allow
anyway. So yes, we have prioritized (1) over (2), and it has "always" been that
way.

The alternative you describe, which I wouldn't mind at all since it allows more
valid constructors, gives us constructors that are *const only*.

It's not allowed by leaving the the current specification unchanged. A const
expression that is not actually compile-time constant is a compile-time error.
If you write:
   const C(x) : x = const D(x);
and this would be a "const only" constructor (since using it with `new` would
not be valid) then there is no semantics for it in the spce. There is no text
saying that `new C(42)` could be invalid. It would fall between the cracks of
the current spec, and not have a specified semantics if it isn't a compile-time
error.

For the last sentence: Oh yeah! const/new/auto construction. Much easier if
const/new is optional in a potentially const scope :)

FWIW, the spec basically treats const constructors as two different constructors
- one used at compile-time and one used at runtime (for example String.+
canonicalizes at compile time, but not necessarily at runtime, which means that
`const C(x, y) : z = x + y;` may need to distinguish between `const C("a","b")`
and `new C("a","b")`.
The VM only has one constructor implementation which is the cause of some of
their issues with allowing non-constants in const constructor calls.

 
 \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}