Discussion: Always explicitly type null-conditional operator ?.

[lachbaer]

When having a class like

class A
{
    int x { get; set; }
    public int y;
}
var cA = new A();

the null-conditiona operator ?. always converts the non-nullable type to a nullable-type:

var z = cA?.x;  // type of z is now 'int?'

That has confused me already many, many times! Like in the following case:

var z2 = cA?.x ?? 12;  // type of z2 is 'int' 

Latter especially when it comes to the default-coalescing-operator ?? (#328), that I have implemented

I'd like to discuss if a mandatory explicit cast could help to avoid the misunderstanding.

var z2 = (int?) cA?.x ?? 12;  // the cast is mandatory to compile!

I would also like to point out, that the implicit conversion to Nullable stands in the specs, but not in the ordinary help pages (https://msdn.microsoft.com/en-us/library/dn986595.aspx).

[HaloFour]

The described behavior is by design and had already been argued at some depth on Codeplex. Changing it to return a non-nullable value type or to require an explicit cast would both be a breaking change and not make any sense.

[lachbaer]

@HaloFour
But do you have any suggestion on how to make the whole construct more obvious?
First step would surely be to update the help for the operator.

[HaloFour]

It certainly wouldn't hurt for the C# Guide to make that more explicit. The example code explicitly uses nullable value types, from which their non-nullable counterparts can be implicitly cast, so the code would compile either way.

[jveselka]

@lachbaer

var z2 = cA?.x ?? 12;  // type of z2 is 'int?' 

Thats not true. z2 is actualy int.

[Unknown6656]

I might be wrong here, but it should work if you use

int z2 = cA?.x ?? 12;

instead of

var z2 = cA?.x ?? 12;

[lachbaer]

@zippec
Yes, you're right. I have corrected that. Thanks.

But you see, that is the 'confusion' I am talking about. I am surely not "dump" or "wanting" and believe that I am average when it comes to programming - you know, the middle of a Gaussian bell curve. When it sometimes confuses me, it surely isn't clear to others as well. That should be helped!

@Unknown6656
The essence of your idea isn't that unrealistic. Besides from coding styles (like make all locals defined with 'var' if possible) a code analysis could propose to explicitly type that expression in case the null-coalescing and null-conditional operators fall together and the outcome is not a reference type.

[MadsTorgersen]

There's no way we will do this as proposed, as it is a breaking change.
Leaving open to facilitate discussion.

[lachbaer]

@MadsTorgersen

There's no way we will do this as proposed

Sure, that's why this is only a discussion and not a proposal 😃
But maybe there is a way to improve the understanding of this quite "complex" operator in the C# guide or even by displaying information in VS? Yet, I don't know how 😉

[jnm2]

I'm honestly not sure why playing around with the operator doesn't make everything intuitive. It's satisfying when your intuition that it should return a non-nullable is confirmed. It's like any language feature in that way.

Since you know intuitively that null is impossible, it's nice that the compiler makes that knowledge type safe. This is like complaining that a hypothetical Math.Square returns a NonnegativeDouble instead of a double. No, that makes sense, because it's impossible for a squared real number to be negative.

[lachbaer]

The intent for this discussion arised from an insufficient knowledge of the underlying processing and casting of the '?.' and '??' operators. Except from the C# language specification this knowledge is not easily gained from the common C# guide and help pages as well as from common C# learning books.

My recommendation is to update the official guide and language help to give more insights on the conversions those operators do.