Unable to compile conditional access expression in context of expression-bodied void method/lambda expression about roslyn

[controlflow]

And from language design perspective: this whole idea of allowing more conditional access expressions to compile in context where value is ignored (is it defined by spec?) feels awkward and ad-hoc. What kind of scenarios this solves?

As a tooling developer, I have to disable 'introduce variable' refactoring for such expressions and this may be confusing for developers. Also I have no idea of what semantic model should tell about type of such c?.M() expression. Is it T (I think so) or void?

Maybe (I'm not sure), it's better to allow such calls of methods with non-liftable return types in any context, but simply lift unconstrained T type (and other non-liftable types) into void type?

[theoy]

I think the goal is more to allow it in contexts where the normal '.' dispatching is allowed - for example method calls that return a value are allowed as statement expressions.

The user intention is to find places where a NullReferenceException would normally occur and instead allow for a graceful null-propagation (or at least a lack of throwing) to occur.

[theoy]

By the way, great catch! I'm thrilled for all of the valuable points that you've been able to help us find as we are trying to land Roslyn v1. 😄

[controlflow]

😉

[VSadov]

It is allowed to have void returning conditional accesses in statement expression scenarios. Scenarios like resource?.Dispose() or event1?.Invoke() seem very useful.
Since we agree on allowing void in such scenarios, it makes sense to remove nullability requirement as well.

[AlekseyTs]

I believe this issue has been addressed already. @VladimirReshetnikov, please verify and close if appropriate.