[Proposal] Extended member null coalescing operator

[Pyrdacor]

Extended member null coalescing operator

So we have the null coalescing operators ?? and ??=. We can express things like:

string foo = bar ?? "some text";
string foo = bar?.text ?? "some text";

But what if I want to express this shorter:

string foo = bar != null ? bar.text : "some text";

This is not the same as the example above because foo will actually be null if bar is not null but bar.text is.

My suggestion would be a new operator: ??. together with :.

Example

// foo is "some text" if bar is null, otherwise it is bar.text (even if bar.text is null!)
string foo = bar??.text : "some text";

So basically a??.b : c is added which means b is used if a is not null and c otherwise.

I had this last use case so often lately and the null coalescing operator wasn't much of help in those cases. So it would be nice if this would be possible.

[HaloFour]

Moreover the construct is limited if the member is not a nullable type

This is not the case anymore: SharpLab

IMO the other scenarios you've described don't feel like they would be terribly common, at least enough to warrant their own flavor of operator. I don't find the ternary operator to be onerous in those cases. What are some real-world use cases?

[Joe4evr]

Moreover the construct is limited if the member is not a nullable type

This is not the case anymore:

Was it ever? Far as I'm aware, using ?. and ?? with value type expressions has always worked since ?. was introduced.

[HaloFour]

@Joe4evr

Was it ever? Far as I'm aware, using ?. and ?? with value type expressions has always worked since ?. was introduced.

I think you're right. Maybe thinking of the issues with nullable type targeting with ternary operations which should now be resolved due to better target typing?

[Pyrdacor]

Moreover the construct is limited if the member is not a nullable type

This is not the case anymore:

Was it ever? Far as I'm aware, using ?. and ?? with value type expressions has always worked since ?. was introduced.

Damn this of course was some kind of brain fart. I will remove this use case.

[Pyrdacor]

IMO the other scenarios you've described don't feel like they would be terribly common, at least enough to warrant their own flavor of operator. I don't find the ternary operator to be onerous in those cases. What are some real-world use cases?

Reading some member of an object and provide a default value if the object is null seems not as a rare case. A use case would be reading a single value from a configuration. But there are plenty imo.

If the config object is there I want to use its value even if it's null cause this is a valid configuration value.

[canton7]

string foo = bar is { } x ? x.text : "some text";

That's not too long, is it? It's certainly clearer to me than the proposed, and only a few characters longer.

[Pyrdacor]

@canton7 How is this clearer or short enough?

Please compare clearness and length yourself:

• x is {} q ? q.y : z
• x??.y : z

If I see the second one and know the ?? operator, it is pretty much clear what to expect.

Additional information:

• x ?? y is short for x != null ? x : y (with only 1 evaluation)
• x?.y is short for x != null ? x.y : null (with only 1 evaluation)
• x??.y : z is short for x != null ? x.y : z (with only 1 evaluation)

So the result of the new expression is a combination of the other two. And this is totally reflected in the syntax (?? and ?. becomes ??.). The exception is the additionally required colon but I can't think of a better solution just yet. But maybe there is one. Pattern matching is definitely not.

@HaloFour Besides use cases the operator would allow single evaluation which is not possible without a temporary variable at the moment imo.

[canton7]

@Pyrdacor Exactly, I count 10 characters, or a couple of extra seconds to write, if that. Try and add up the amount of time you'd save, vs the amount of time the team will have to spend specifying, implementing, testing, documenting, supporting, etc.

I think I can fairly confidently say that I personally would spend more time learning about this syntax (and having to recognise it very occasionally in the wild) than I'd ever save by using it.

If I see the second one and know the ?? operator, it is pretty much clear what to expect.

I don't think that's universally true at all. I read that at first as x ?? .y, and wonder why it's .y and not just y. Even when I know what it's trying to mean, I have a lot of trouble with that floating : -- colons on their own are normally matched to an earlier ?, but I can't see one of those. I still stare at it for a while trying to work out how the mutant lovechild of ?? and ?. became part of a ternary.

C# isn't just about shaving characters off expressions. One of the main aims is still to be readable.

[Pyrdacor]

You got me with that mutant lovechild. :D

It's not only about characters. Such expression would only evaluate the object (e.g. a property) once and should be thread safe. There is something for the object itself but not for the member access.

My syntax suggestion is not carved into stone. But a robust expression for member access of potential null objects isn't the worst idea imo.

x.y ?! z would be a shorter variant. And is probably more readable than x.y ?. z which would be another syntax.

Maybe it would be a general approach to allow this:

x ?? y : z;
// equal to
x != null ? y : z;

The latter one is often needed.

[canton7]

Such expression would only evaluate the object (e.g. a property) once and should be thread safe.

We have that already with patterns, as I demonstrated.

But a robust expression for member access of potential null objects isn't the worst idea imo.

Thing is, the bar's a bit higher than that. New language proposals start at -100 points.

x.y ?! z would be a shorter variant. And is probably more readable than x.y ?. z

What these miss is a way to handle:

var temp = a.b;
var result = temp != null ? temp.c : z;
// or
var result = a.b is { } temp ? temp.c : z;

a.b.c ?! z is unclear as to whether a or a.b is being null-checked.

[Pyrdacor]

What these miss is a way to handle:

var temp = a.b;
var result = temp != null ? temp.c : z;
// or
var result = a.b is { } temp ? temp.c : z;

a.b.c ?! z is unclear as to whether a or a.b is being null-checked.

That's why my original idea added the operator at the location where the null check should be done.

The pattern matching version is very ugly for that purpose and nobody beside hardcore c# devs will be able to read or understand it. The ??. operator will at least be understood by people who know the operators ?? and ..

Moreover it introduces a variable name thats only purpose is to fulfill some syntax workaround.

[canton7]

That's why my original idea added the operator at the location where the null check should be done.

Indeed, I'm just pointing out that your later proposed syntaxes don't cover this case.

The pattern matching version is very ugly for that purpose and nobody beside hardcore c# devs will be able to read or understand it ... The ??. operator will at least be understood by people who know the operators ?? and ..

Given that your proposal will be seen far less often than pattern matching and ternaries (is { } foo is by now a fairly well-known not-null check, and a ternary is already familiar to most), I suspect only an ultra-hardcore subset of hardcore C# devs will be able to read or understand it! At least the pattern-matching approach here is built out of standard building blocks which are used in more place.

I'm apparently a normal hardcore C# dev, as I understood the pattern matching one, and had a lot of trouble with your proposed ??. ... : operator (which I described above).

[Pyrdacor]

I also understand the postfix increment operator, assign operator and loops but the following is still not very easy to read:

int x = 0;
int y = 0;
while ((y = x++ * 3) + y < 42)
   ...;

I use pattern matching when I want pattern matching and not as a workaround for robust null checks. Of course an advanced C# dev will understand it and then he will get the shivers. Don't get me wrong. It is a valid way to express what I want but I wouldn't do so as it would drastically reduce the readability and disguise the initial trivial purpose by introducing pattern matching in a place where it isn't expected nor really needed.

[canton7]

Right, but you can work it out based on the knowledge you have. In contrast to new alien syntax, which you need to go and look up.

Only an advanced C# dev would know about your proposed new syntax. Everyone else will continue to write this the way they do already, with a ternary and a temp if necessary.

It seems you're trying to argue for a new niche syntax, by complaining that the existing less-niche alternatives are too niche. Which seems backwards. What you're proposing is not going to become more mainstream than the tools which are out there already.