Perform tighter static checks on potentially constant expressions

[eernstg]

Consider the following program:

class Test {
  const Test(this.values): assert(values != null && values.length != 0);  
  final List<int> values;
}

const test = Test([1,2,3]); // Compile-time error

This yields a suboptimal developer experience because values.length is accepted as a potentially constant expression, but there could never be an invocation of the constant constructor which doesn't fail (because values doesn't evaluate to a String).

We could detect and flag this kind of compile-time error at the constructor declaration in many cases, rather than delaying it to the call sites: We could require that in order for e.length to be a potentially constant expression, the static type of e must be either String or dynamic.

The current notion of potentially constant expression is purely syntactical, so we may wish to ensure that this doesn't introduce anything substantially different about potentially constant expressions. However, the static type of e does not depend on the status of e or any of its subexpressions being constant or potentially constant. It would amount to a static type which is already used anyway when deciding on whether to accept e.length as a correctly typed expression. It's just a bit more strict, because an e of type List<...> will be rejected.

We could do similar things for other potentially constant expressions. E.g., we could require for e1 + e2 to be a potentially constant expression that the static type of e1 and e2 is dynamic, num, int, double, or String. This would allow e1 to have static type int and e2 to have static type String, but that kind of mismatch would be caught by the normal type checks on the expression.

[lrhn]

The current behavior was chosen as a result of a request from Fasta, because they wanted to be able to detect and reject potentially constant expressions without doing type inference first.

I think we should introduce the notion of an expression "being in a constant, potentially constant or normal context", so that we can introduce different rules for those.

In that case, an expression of the form e.length in a potentially constant context can be a compile-time error if the static type of e is not String, dynamic or Never. It's still a potentially constant expression, it just has a special potentially-constant only type error.

[eernstg]

We already have the notion of constant contexts (which is specifying a subset of the locations where an expression must be constant, and here we need all of them), but it is certainly also true that we have to specify the locations where an expression must be potentially constant, and say that these type related errors only apply there.

With respect to the phase dependencies in tools: It should be possible to check the syntactic criteria for these must-be-potentially-constant expression first, then gather them in a set, and finally check the type related criteria at a point in time where type inference has been performed. This is somewhat involved because rewriting steps need to preserve that set, but a similar approach is used in the front end with redirecting factory invocations and in some cases with non-function type aliases, so there is some prior art.

[lrhn]

and say that these type related errors only apply there

Potentially constant is actually the simpler one because things are never potentially constant unless they are inside a const constructor, and then they always are.

The tricky one is constant evaluation. We say that "a".length is a compile-time constant expressions even when it occurs outside of contexts forcing it to be constant. That's not a particularly interesting example, but it is important for string canonicalization, so "1" and "${"a".length}" are both constant expressions that are canonicalized to the same value.

However, "${const[1].length}" is a potentially constant expression, and probably a constant expression, if it occurs in a constant context (and then it's an error to take the length of a list), but is it not constant if it occurs in a general context? It can't be, because if it was constant, then it would be an error, and it's not an error, so it can't be constant.
Not sure we are specifying it that clearly (and that's not clear!), so we might need to look at constant contexts again anyway.

[eernstg]

Potentially constant is actually the simpler one because things are never
potentially constant unless they are inside a const constructor, and then
they always are.

Well, we specify that a set of expressions are 'potentially constant', and we certainly cannot report an error for const [1].length everywhere. So we do need to specify the locations where an expression is required to be potentially constant, and then we can specify the type related errors for those occurrences. But I agree that this isn't hard, the locations are (1) an argument passed to the target constructor in a redirecting generative constant constructor, and (2) an expression in the initializer list of a generative constant constructor.

"1" and "${"a".length}" are both constant expressions that are canonicalized to the same value.

I don't think we need to worry about constant expressions here. We just need to see that we can add the type related requirements to expressions that must be potentially constant, and then we can get the better static analysis. Btw, we don't actually specify that constant expressions of type String are canonicalized, it is only specified for symbols and for constant list/map/set literals and constant object expressions. But this makes no difference for the improved static analysis of required-potentially-constant expressions.

we might need to look at constant contexts again anyway

I think it is working already: Certain expressions are required to be constant. The requirements for being a constant expression in some cases include that subexpressions evaluate to an object. So the requirement is not fulfilled when the evaluation would throw (like 1 ~/ x where x is bound to 0), and it is not fulfilled when the evaluation violates a constant-specific constraint (like x.length where x has type dynamic and is bound to a list).

The new compile-time errors that are proposed here will cause some programs to be rejected based on the types of some expressions. This does not involve any compile-time expression evaluation steps at all, so I'd say that it can be discussed without reference to constant expressions.

[eernstg]

@lrhn provided a more detailed list of these potential typing improvements here: #2209 (comment).

Here's the list:

• e.length if the type of e is not assignable to String (so String, dynamic or Never, and probably not Never in practice).
• e1 + e2 if the type of e1 is not assignable to num or String. Same for *.
• e1 | e2, e1 & e2, e1 ^ e2 if the type of e1 is not assignable to int or bool.
• e1 - e2 if the type of e is not assignable to num. Same for all the remaining number operators, including prefix ~e and -e.
• "${e}" if the type of e is not assignable to one of String, num, bool, or Null.
• e1 == e2 if the type of e1 does not have primitive equality, and the type of e2 is not assignable to Null.

[Edit: Updated the rule about == to match the upcoming change where == requires primitive equality.]

[lrhn]

The == might be need to be updated if we have already landed the change to allow the LHS to be any type with primitive equality (mainly to allow enums). Otherwise this would be a good time to do so.

[eernstg]

Thanks! That change has not yet landed, cf. #1811, and any time is a good time to do it! ;-)

[mraleph]

Did we ever consider allowing e.length specifically on builtin list types, instead of outlawing it altogether? I can't really see the problem with that given that current specification resolves .length when receiver is known. It's really surprising that this does not work.

I understand that it might be good to emit an early error when we see constructor itself --- and with List interface type we don't have enough information to do that. But on the other hand I think allowing List.get length has more value to users then an early compile error in constructor.

• e.length if the type of e is not assignable to String (so String, dynamic or Never, and probably not Never in practice).