Should we allow "?." as a null-aware element + dot shorthand?

[munificent]

The combination of null-aware elements and dot shorthands means this is now valid syntax:

list = [? .property];

However, if you remove the space between the ? and ., then it gets lexed as a single ?. token and you get a syntax error in:

list = [?.property];

I have a fix out to make sure the formatter doesn't output this syntax (dart-lang/dart_style#1642), but it's still a footgun if a user writes this.

Should we change the language so that it's allowed to not have a space there?

This is exactly analogous to how we handle the >> in List<List<int>> where we "un-lex" it from a right-shift >> to > > if we're in a context where right brackets are expected.

As far as I can tell, we should be able to do the same thing for a null-aware element followed by a dot shorthand. A null-aware element in that position will always be in a context where a null-aware access (i.e. ?.) can't appear.

I know it's hacky to have the parser and lexer interact in this way, but we already did for >> so maybe we should make the language accommodate ?.shorthand too? Otherwise, we are basically recapitulating C++'s mistake (which they finally fixed) and forcing users to remember to put a space in ? . or it won't do what they want.

cc @bwilkerson @jensjoha for thoughts on how this would interact with parsing and error handling.

[muhammadkamel]

Can we add two dots instead

[FMorschel]

Can we add two dots instead

1. I think this gets us to the same place since we would then have the cascade operator
2. I don't think that will be coherent with other null-aware syntax and may confuse the user

[bwilkerson]

I can't think of any way that ?. would negatively impact our ability to recover. And, of course, allowing it would reduce the number of cases where recovery would be required.

[munificent]

negatively impact our ability to recover

I'm not sure what you mean by this. Are you saying yes we could handle ?. as two tokens when it appears in a context where it doesn't make sense for it to be one?

[bwilkerson]

Sorry for not being clear. Yes, I think it's fine to handle ?. as two tokens.

[lrhn]

For specification, er could say something about scanning being contextual, so when the parser is expecting an element, a following ?. is tokenized as just ? first, and then continuing in a non-element context.

That's not how it'll be implemented, the scanner will just tokenize as ?., and the parser will split that token into two if needed.

[munificent]

@kallentu, thoughts?

[kallentu]

From a user standpoint, what you're proposing seems to be what I would want and expect.

From a parser implementation standpoint, seems to be fine by me? I don't have a good visualization of what/where changes need to be done, but if @jensjoha and @chloestefantsova see no issues, SGTM

[munificent]

I don't have a good visualization of what/where changes need to be done

I don't know where in the lexer/parser pipeline the change needs to happen but if the parser can parse [?.foo] without it being a syntax error than it's working.

If we decide to do this, let me know, and I'll revert dart-lang/dart_style#1748 because that change will no longer be needed in the formatter.

[lrhn]

I tried implementing it. Not too hard: https://dart-review.googlesource.com/c/sdk/+/442480

[chloestefantsova]

but if @jensjoha and @chloestefantsova see no issues, SGTM

SGTM too 👍

[jensjoha]

It'll probably be fine.