Null propagation expression does not allow `!` as a nested operator form (VS 16.8, .NET 5)

[agocke]

See dotnet/docs#17988

This means that the only correct parse of

var x = a?.b.c!.d.e;

is (a?.b.c)!.d.e, which prevents usage of null-forgiving in a chain of null-propagating accesses. To remedy this we could accept ! as an optional token after every simple name in the null-propagating non-terminal.

cc @jcouv @gafter

---

Was discussed in LDM 6/17/2020. There is agreement/support, but we'll need to investigate and make a concrete syntax proposal. Also, there is desire to keep terminal ! parsing as today: a?.b.c! would still parse as (a?.b.c)!.
For reference, the current syntax.

[AntonLapounov]

I was not aware of this issue and filed dotnet/roslyn#43659.

[RikkiGibson]

It doesn't feel like accepting an optional token after a simple name is sufficient for a case like Prop?.Method1()!.Method2(). Could we solve this by considering !. a distinct operator which accesses a member and suppresses the nullable warning on the receiver?

[jaredpar]

Looks like the NRT Spec needs to be updated. Presently it says

The postfix ! operator has no runtime effect - it evaluates to the result of the underlying expression. Its only role is to change the null state of the expression, and to limit warnings given on its use.

That is not true though cause it changes the manner in which conditional expressions are parsed hence their runtime behavior. Here is a simple sharplab sample that demonstrates this.

[333fred]

Well, that's how it should be. This is a bug that we need to fix.

[gafter]

That is not true though cause it changes the manner in which conditional expressions are parsed hence their runtime behavior.

Yes. Also parentheses have runtime behavior for the same reason.

[RikkiGibson]

If nobody has written a syntax proposal for this I would be happy to take a stab at it.