Grammar error for Paul

[IndieRobert]

Paul?
clientTable?["seat${seat}Pot"] += clientTable?["seat${seat}Front"] + (clientTable?["bettingRound"] == 1 ? (clientTable?["seat${seat}Dead"]) : 0);

compiles

clientTable?["seat${seat}Pot"] += clientTable?["seat${seat}Front"] + (clientTable?["bettingRound"] == 1 ? clientTable?["seat${seat}Dead"] : 0);

doesnt

From quadcore

[johnniwinther]

Rewritten example:

method(dynamic a, dynamic b) {
  a?[""] += a?[""] + (a?[""] == 1 ? a?[""] : 0);
  b?[""] += b?[""] + (b?[""] == 1 ? (b?[""]) : 0);
}

results in

temp/issue48460.dart:2:47: Error: Expected ':' before this.
  a?[""] += a?[""] + (a?[""] == 1 ? a?[""] : 0);
                                              ^
temp/issue48460.dart:2:47: Error: Expected an identifier, but got ')'.
Try inserting an identifier before ')'.
  a?[""] += a?[""] + (a?[""] == 1 ? a?[""] : 0);
                                              ^

meaning that the first line doesn't parser but the second does.

@IndieRobert Do that reflect you problem?

[eernstg]

Here's a smaller example:

void main() {
  var h = [1] as List<int>?;
  true ? h?[0] : 0;
}

This library is rejected by the parser, and it is accepted if we use (h?[0]). So the problem could be the ? in the null-aware indexed access h?[0]. At that position we must have an <expressionWithoutCascade>, and h?[0] is a <postfixExpression>, so it should be accepted without the parentheses.

[IndieRobert]

Yup this is it

[jensjoha]

I haven't actually stepped through yet, but my guess is this:

When the h?[0] syntax was introduced instead of the h.?[0] we found that we had to disambiguate between a null-aware index operation and a conditional expression by trying if it can parse as a conditional expression, and if it can that's what we do (#40267 (comment)).

I think that's what's happening here: looking at h?[0] : 0 it can be parsed as a conditional expression, so it is.

[jensjoha]

Meaning that

true ? h ? [0] : 0;

is parsed as

true ? (h ? [0] : 0) /* missing stuff here */;

and

true ? h ? [0] : 0 : 1;

is parsed as

true ? (h ? [0] : 0) : 1;

[jensjoha]

I think that's what's happening here: looking at h?[0] : 0 it can be parsed as a conditional expression, so it is.

Stepping through the parser confirms this:

For true ? h?[0] : 0; when it sees the first ? it concludes it's a conditional expression. It continues to parse the expression before the colon. In doing that it sees ? [ and it checks if it can be parsed as a conditional expression. It can, so it does. Then we get back from the parsing of the (first) conditional expression (before the colon) and now we need there to be a colon. But there isn't, so it complains.

To the best of my knowledge this is what the language team wanted (e.g. feature-specification and comment).

I'll remove my assignment and /cc @eernstg @lrhn @leafpetersen

[lrhn]

I concur, that's what I expect to happen too.
Yes, it's annoying that something that can be parsed correctly is instead disambiguated into something that doesn't parse, but that's the cost of doing local disambiguation. (The cost of doing non-local disambiguation is much higher parsing cost at less predictability.)

Wrap the entire thing in { ... : 0}, and then both parsings become valid - {true ? h ?[ 0 ] : 0 : 0 }, and h?[0]:0 being predictably always treated the same might just be better then.

[eernstg]

Of course, so it is actually working as intended.