Null-conditional operator chaining seems very complicated - am I missing something?

[paulcscharf]

A bit of context

I learned today that the null-conditional operators (?. and ?[]) impact more than just a single member access, but in fact the entire call chain that may follow as is explained in the docs:

The null-conditional operators are short-circuiting. That is, if one operation in a chain of conditional member or element access operations returns null, the rest of the chain doesn't execute. In the following example, B is not evaluated if A evaluates to null and C is not evaluated if A or B evaluates to null:

A?.B?.Do(C);
A?.B?[C];

What confuses me

So far so good. What confuses me however is that very subtle changes to this sort of chain can have a big impact on what actually happens:

A?.B?.C

• 😴 A is null: do nothing else, the whole expression is null
• 🕵️‍♂️ A is not null: call B, call C only if B is not null

A?.B.C

• 😴 A is null: do nothing else, the whole expression is null
• ⚠ A is not null: call B and C (may cause NullReferenceException if B is null)

(A?.B).C

• 💥 A is null: do not call B, but DO call C on null (probably causing a NullReferenceException)
• ⚠ A is not null: call B and C (may cause NullReferenceException if B is null)

This last case is the most confusing to me. It LOOKS like it should be 100% identical to A?.B.C (after all, that's what happens if we're using .), yet it isn't. The same happens if we assign A?.B to a variable and then call C on it.

This is not mentioned in the docs explicitly, though I suppose it is implied by it talking about 'chains', with the understanding that parenthesis or assigning to a variable break a chain.

What might add to the confusion is that depending on whether A is null, the second case either behaves the same as the first or the same as the third (see matching emoji).

My question(s)

I'm wondering if I'm missing something here, or misunderstanding something. The three cases above behave differently, and each may have good uses. However, it seems to me like this is bound to cause misunderstandings and bugs.

1. Was this considered when designing the feature? Is there documentation on why it works like it does? (I did search for quite a while, unsuccessfully.)

2. Is it perhaps just a case of there not being a cleaner solution without compromising the feature?

3. Or am I perhaps missing something and this is perfectly clear to others?

As things stand, the lesson I've learned so far is to be really careful and ideally avoid chaining after a null-conditional operator to avoid this possible confusion. Please do enlighten me if there's a better way. :)

[CyrusNajmabadi]

You're completely understanding things.

To answer your questions

Was this considered when designing the feature?

Yes. Absolutely. And the behavior you see is intentional.

Is there documentation on why it works like it does? (I did search for quite a while, unsuccessfully.)

It is implied by the grammar rules here. Effectively you get two entirely different shaped trees here. I'm on mobile, but I can try to draw them out for you later!

As things stand, the lesson I've learned so far is to be really careful and ideally avoid chaining after a null-conditional operator to avoid this possible confusion. Please do enlighten me if there's a better way. :)

A simple way to think about it is that you should use ?. If you think the thing preceding you could be null. And that parentheses snips off the tree and makes that an independent chunk.

I can def provide more information if you have more questions :-). But I'm mobile, so this is all brief.

[paulcscharf]

This is already super helpful, thanks! I also just checked the design meeting notes linked by @HaloFour, and between that and your 'simple way to think about it', I'm beginning to understand this better.

Each ?. is really an 'exit branch' for the current chain, which as you say can be broken by parentheses:

(Is this the kind of tree you meant?)

I can see how doing otherwise would mean having to add ?. for the entire chain after the first, which in return would swallow any other nulls that were not expected, making the whole feature less useful. So I think I get why you went with the short-cutting behaviour.

Being able to actually break that chain with parentheses still seems a bit weird, and I can actually only see it making a functional difference with extension methods where the first argument is optional. (We can use ! to break the chain as well, with a very similar result.)

Do you happen to have an example of where we would ever want to continue a chain after ! or using parentheses? It seems to me like this is only useful if we want to force a NullReferenceException at a very specific point, except because of the short-cutting we can achieve the same by just using a regular . to begin with:

• A?.B?.C - never throws (because of null at least)
• A.B?.C - throws if A is null
• A?.B.C - throws only if A != null and B == null
• A.B.C, (A?.B).C, A?.B!.C- throws if either A or B == null

I'll have another think myself as well - perhaps the examples are just too simple.

Thanks again!

[svick]

@amulware I believe @CyrusNajmabadi was talking about syntax trees. You can see the (detailed) syntax trees produced by the C# compiler in tools like SharpLab or LINQPad. Simplified versions of those syntax trees would look like this:

[333fred]

We can use ! to break the chain as well, with a very similar result.

That's actually a bug, we're fixing it in 9: #3393

[HaloFour]

Was this considered when designing the feature?

Yes, this was debated at some length. I think most of the conversations are buried in the archives on CodePlex since they occurred prior to the team migrating to Github. There are language design meeting notes on the subject though:

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

[paulcscharf]

Thanks! Those meeting notes actually really helped me understand this a lot better! (See my response to Cyrus)

[Richiban]

If (A?.B).C is confusing, does this rearrangement help?

var x = A?.B;
x.C;