Null Conditional Member Access breaks expectations. P?.A.B differs from (P?.A).B

[jbt00000]

Just came across something odd when debugging an error

P?.A.B differs from (P?.A).B

This is very unexpected, wacky, and breaks simple extension methods used in many places. Parens aren't supposed to matter with simple order of operations!

All this is tucked away in a note on page 174 in the spec

https://www.ecma-international.org/wp-content/uploads/ECMA-334_6th_edition_june_2022.pdf

Simple use case is below

Extension methods are supposed to be able to take null as the "this" parameter. Which allows folks to write useful extensions such as:

public static IEnumerable<T> NullSafeEnumerable<T>(this IEnumerable<T> e) { if (e == null) return new T[0]; return e; }

and invoke them like

static void TestB(IList<int> l=null) { var cnt = 0; foreach (var e in l.NullSafeEnumerable()) { ++cnt; } Console.WriteLine($"{nameof(TestA)}=>{cnt}"); }

In this additional case of the null conditional member access, we have

class Container { public IList<int> TheList; } static void TestD(Container c=null) { var cnt = 0; foreach (var e in c?.TheList.NullSafeEnumerable()) { ++cnt; } Console.WriteLine($"{nameof(TestB)}=>{cnt}"); }

which fails, but the following with parens succeeds

static void TestC(Container c = null) { var cnt = 0; foreach (var e in (c?.TheList).NullSafeEnumerable()) { ++cnt; } Console.WriteLine($"{nameof(TestB)}=>{cnt}"); }

We have the pattern shown in TestD all over our app. No idea how many others are caught up in this unexpected scenario!

[CyrusNajmabadi]

Parens aren't supposed to matter with simple order of operations!

That is definitely not true. Indeed, parens exist precisely to affect order of operations and to change things like precedence. This is very intentional exactly so you can get the different semantics here (each of which are useful in different circumstances).

[HaloFour]

This is expected, the null-conditional operator is right-associative and short-circuits the remainder of the expression. Without the parenthesis the attempt to access member B is completely skipped. But with the parenthesis you force the expression to be evaluated and then you attempt to access member B from the result of that expression.

See: https://github.com/dotnet/csharplang/blob/main/meetings/2014/LDM-2014-04-21.md#null-propagating-operator-associativity

[jbt00000]

Yes, after reading the footnote in the specs I saw it was a right-associative operator. And yes, I was able to clean-up the code base before posting the initial message. My issue, as jnm2 pointed out, is that it causes problems for people who didn't read the spec in detail.

Seeing basic example code, and in fact, many implementations, this would not come up.

I'm not calling this out to say change this behavior and break even more code, but this is precisely the type of decision that causes hard to catch errors in people code. It would have been more natural to have the default behavior as (P?A).B and leave alternate behavior to parens P?(A.B) .

[HaloFour]

Like most things it's something you learn once. The associative-ness of the operator was discussed in depth over some time and the initial plan was to be left-associative but that was considered to have short-comings as well as the compiler would have to evaluate the remainder of the chain and a single missed ? could still result in an NRE if any expression prior to that point evaluated to null.

[jbt00000]

+1 to once you learn it... Now, I just need to teach my team.

I rarely read the details about the debate of new language features (other than with async IAsyncEnumerables and !!), but realize there are many use cases and that precision matters. I hope that when non-obvious winners emerge, there are a few more publicized examples of don't do this. Cracking open the specs is something I doubt most people will do.

[CyrusNajmabadi]

It would have been more natural to have the default behavior as (P?A).B

I personally disagree with that. With that approach, people would have to do things like a?.b?.c?.d?.e all to deal with the fallout of a being null. With the approach we took (intentionally), you do the null prop op where it can actually introduce null into the system, and the entire rest falls away.

[jnm2]

The Shouldly assertion library has also struggled with this, where people write foo?.Bar.ShouldBe(42); and don't realize they should be writing foo.ShouldNotBeNull().Bar.ShouldBe(42);. If we get time, we'll work on an analyzer for this.

For the null-safe enumerable use case specifically, ?? [] would be enabled by #5354 and would cater to null-safe foreaches:

foreach (var e in c?.TheList ?? [])
{

[TonyValenti]

I really just want a foreach?