Use separate grammar rules for null-aware elements.

[munificent]

Stuffing the ? directly inside expressionElement and mapEntryElement lets us reuse some existing specification around leaf elements, but is otherwise confusing because it makes the case analysis for the different kinds of elements non-disjoint.

This fixes that by defining entirely separate rules for null-aware elements.

[lrhn]

Do we need to do something special for coercions here, or will the value be coerced before the null check?

void main() {
  // True, but compiler doesn't know that.
  var b = DateTime.now().millisecondsSinceEpoch > 0;
  var l1 = <Function>[?(b ? CallableObject() : null)];
  var l2 = <int Function(int)>[?(b ? id : null)];
}

T id<T>(T value) => value;
class CallableObject {
  void call() {}
}

Will these list literals work or fail to compile?

If we coerce before null-checking, then we coerce CallableObject? to Function? which is not supported, so it's a compile-time error. Same for coercing T Function<T>(T)? to int Function(int)?. Neither of these are allowed:

  Function? v1 = (b ? CallableObject() : null);
  int Function(int) v2 = (b ? id : null);

If we coerce after null-checking, the code should works. And it's probably what the author wanted.
So should we?

That would either mean being explicit about where we do coercion, or somehow suggest to inference that the null check is not a coercion-point (a concept we haven't specified other than by the algorithm used.)

WDYT? @stereotype441

The static semantics with a context element type E would be (paraphrased):

Let S be the static type of e in context E?. Let S' be NonNull(S).
It's a compile-time error if S' is not assignable to the greatest closure of E.

and runtime semantics of executing ?e would be:

Evaluate e to a value v.
If v is not the value null, then

• if the runtime type of v is a subtype of E, let w be v, otherwise coerce v from type S' to a value w of type E. (Which is always possible because S' is assignable to E.)
• Then append w to result.

(Not sure dynamic has an issue, downcasting before or after both work.)

[munificent]

Good question! I filed a bug so we can discuss this more: #3821

[lrhn]

Here we probably want to coerce both after the null check, although it's probably usually the value where it makes sense (functions are bad keys).