Should null-aware subscripting use `?[` or `?.[` syntax?

[stereotype441]

The draft proposal currently extends the grammar of selectors to allow null-aware subscripting using the syntax e1?.[e2], however we've had some e-mail discussions about possibly changing this to e1?[e2], which would be more intuitive but might be more difficult to parse unambiguously.

Which syntax do we want to go with?

[munificent]

var wat = { a ? [b] : c };

Is this a set literal containing the result of a conditional expression, or a map literal containing the result of a null-aware subscript?

I think we'll probably want to do ?.[]. Also, the cascade is ..[], so this is arguably consistent with that.

[leafpetersen]

I believe the suggestion that @bwilkerson made was that ?[ is parsed as single token, and ? [ is parsed as two. So for your example:

var set = { a ? [b] : c };  // Set literal
var map = { a?[b] : c}; // Map literal

Note that Swift and C# both use ?[]. Swift seems to be able to correctly disambiguate between conditional expressions and null aware subscripts, but doesn't seem to use tokenization to do so.

    var x : Array<String>?;
    var t1 : String? = x?[0]; // Treated as a subscript
    var t2 : String? = x? [0]; // Treated as a subscript
    var t3 : Array<Int>? = x == nil ? [0] : [3];  //Treated as a conditional expression
    var t4 : Array<Int>? = x == nil ?[0] : [3];  //Treated as a conditional expression

[lrhn]

Swift does seem to use tokenization to distinguish, it's just whether there is a space between the x and then ? which matters, not between ? and [.

Whether to trigger on x?, ?[, or even x?[, without whitespace should probably be determined by where we want to break lines.

var v1 = longName?
   [longExpression];
var v2 = longName
   ?[longExpression];
var v3 = longName?[
  longExpression];

I can't see any one to prefer. So, what do we do for ?.?

var v4 = longName
    ?.longName();

That does suggests that we want ?[ to be the trigger, for consistency.

C# does not have the issue because [...] is not a valid expression.

[jodinathan]

I think the question mark aways close to the variable as subscript is better to read.
x?

[munificent]

Leaf and I spent some time talking about this at the whiteboard. My take on it going in is that both options have some things going for them:

foo?[bar]:

• Follows C# and Swift [EDITED: Kotlin doesn't have this operator]
• Terse
• Mirrors !: foo![bar]

foo?.[bar]:

• Mirrors cascade: foo..[bar]
• Mirrors other null-aware method syntax: foo?.bar()
• Avoids the nasty ambiguity in: { foo?[bar]:baz }

We spent a while trying to come up with ways to avoid the ambiguity with ?[. A couple of them are probably workable, but none feel particularly great to me. In particular, relying on whitespace can really harm the user experience. In theory, it's not a problem in formatted code. But many users write un-formatted Dart code as an input to the formatter. And that input format would thus become more whitespace sensitive and brittle in this corner of the language. So far, those kind of corners are very rare in Dart, which is a nice feature. (The one other corner I recall offhand is that - - a and --a are both valid but mean different things.)

We talked about eventually adding null-aware forms for other operators: foo?.+(bar), etc. If we do that, we'll probably want to require the dot, in which case requiring it for subscript is consistent with that future.

Another addition we have discussed for NNBD is a null-aware call syntax. If we don't require a dot there, it has the exact same ambiguity problem:

var wat = { foo?(bar):baz }; // Map or set?

So whatever fix we come up with for the ?[ ambiguity, we'll also have to apply to ?(.

Finally, Leaf wrote up an example of chaining the subscript:

foo()?[4]?[5]

To both of us, that actually doesn't look that good. It scans less like a method chain and more like some combination of infix operators. A little like ??. Compare to:

foo()?.[4]?.[5]

Here, it's more clearly a method chain. Communicating that visually is important too, because users need to quickly understand how much of an expression will get null-short-circuited.

Putting all of that together, it seems like the ?.[ form:

• Avoids ambiguity problems. (The lexer already treats ?. as a single "null-aware" token.)
• Extends naturally to a null-aware call.
• Extends to other null-aware operators.
• Leaves Dart a more robust input language to the formatter.
• Actually looks pretty OK in a method chain.

So we're both leaning towards ?.[. If users ask why we do a different syntax from Kotlin and Swift, I think it's easy for us to show the ambiguous case and explain that it's to avoid that.

[leafpetersen]

@lrhn I'm going to close this in favor of ?.[ since I think I was the only one still on the fence and I think I've moved into the ?.[ camp now. If you've come around to ?[, feel free to re-open for discussion.

[lrhn]

LGTM. I did not find the white-space based disambiguation tecniques convincing, they didn't fit well with the current Dart syntax, and I couldn't see any other reasonable way to disambiguate.

[DaveShuckerow]

Question: was any consideration given to the syntax map[?index] ?

This is simpler to remember (IMO) than map?.[index] and appears to avoid the ambiguity problem of wat = {map?[index]:value}.

[lrhn]

The map[?index] notation looks misleading. Reading it, I'd assume that it is checking whether the index is null, not the map.

(On the other hand, that could be a useful functionality by itself: If a function parameter or index operand starts with ?, then if it is null, all further evaluation of that call is skipped and it evaluates to the short-circuiting null value. Since a call or index operation is inside a selector chain, it could have the same reach as ?., and we wouldn't need something new. Probably doesn't work for operators, though.)