Proposal: non-null coalescing operator (meld operator?)

[AartBluestoke]

Problem:
We have several other null coalescing operators to avoid using objects when they are null (?.) but don't have the capability to succinctly express a similar concern about function call parameters.

Proposal to simplify null handling:

Creation of a new binary operator !??
we have both a ?? operator for null handling, and a ! operator for inverting logic, so writing them together intuitively says "only do the following if not null"

The !?? operator is called the value-melding operator. It returns the right-hand operand if the left-hand operand is not null; otherwise it returns null.
The left hand member is provably non-null while evaluating the right hand member.
The resulting value has a type of Nullable<typeof(right-hand operand)>

The proposed operator x!??y can alternatively be expressed as (assuming that :
T? result (x is null)?null:y;

This wording was chosen to mirror the current null-coalescing operator:

This allows expressions such as strict parsing, with null handling:
int? myInt=myString!??Int.Parse(myString);
current equivalent code

myInt = myString is null?null:((int?)Int.Parse(myString));

// not available in object intializer
int? myInt=null;
if(myString != null) {
    myInt = Int.Parse(myString);
}

{
public static Nullable<TOut> Meld<Tin,TOut>(Tin obj, Func<Tin,TOut> rightOperand) where Tin:class where TOut:struct
{
    if (obj is null) return null;
        return rightOperand(obj);
    }	
...
    Int? Result=Meld(parsableString,Int32.Parse);
}

Notes:
I believe with the introduction of null-tracking / provably not-null objects, an operator like this will simplify code in which only some code paths contain nullable objects, by allowing a simple form of "only call this function if these potentially nullable parameter are not null".

In order to implement this as an extension method, as mentioned by
The current implementation of 'Meld' function needs to be split into 2 types NullableMeld and ValueMeld, which either return TOut or Nullable, and would further need to have variants for different numbers of parameters

<edit: there are a few similar posts as noted below; however none of the others have gained traction>

[Unknown6656]

i believe this operator is intuitive to understand, [...]

For me personally, it is not difficult to understand, but I think it is rather hard to track down errors with this in large code bases.

I personally also do not see an explicit need for this proposal, as it is rather a small-ish use case. I would rather see people replace this operator with a short-named, descriptive extension method.

Also, what will happen, if people find more such use case? We will end up with a whole set of operators named .??!, !??=, .!??!?= etc.
I think it gets way to unreadable if we continue at this pace.....

[stuartstein777]

Man, I hate the ?. operator. I see it abused so much and it makes it hard IMO to understand what the control flow is.

I saw this recently from someone I work with

nodes?.GroupBy( x=> x?.Servername, (key, g) => g?.OrderByDescending(y => y?.Role)).FirstOrDefault().ToList();

What does that even do if the various things are null?

I find this int? myInt=myString!??Int.Parse(myString); highly unreadable.

[Austin-bryan]

The operator looks too much like !???!?!???!?!? like a really annoying person asking a question. Not exactly what I want my code to look like.

Also I'm finding this very confusing. If x is not null return y, else return null? Can you give an example of when you wouldn't want to use y if x is null?

It seems very niche, not useful, and confusing because I would expect x to be returned at some point.

The null coalasing operator is something used probably in every class, but yours wouldn't. It's also completely unreadable when you chain them.

Why not just use an extension method:

public static T Meld(this object obj, T rightOperand)
{
    if (obj) return rightOperand;
    else return null;
}
...
Foo(x.Meld(y));

It's only a few characters longer, but much more readable and doesnt involve needing a new feature that everyone else has to deal with. Not everything needs an operator.

Also please reformat your question, your code is unreadable.

[orthoxerox]

It's basically SelectMany on a nullable value:

int? myInt=myString!??int.Parse(myString); is equivalent to int? myInt = myString.SelectMany(int.Parse).

It's kinda similar to #431, except less generic.

[CyrusNajmabadi]

nodes?.GroupBy( x=> x?.Servername, (key, g) => g?.OrderByDescending(y => y?.Role)).FirstOrDefault().ToList();
What does that even do if the various things are null?

First, if nodes is null, you get null back. Otherwise, .GroupBy(...).FirstOrDefault().ToList() is called on it. Second, the ... contains two arguments, both of which are lambdas.

The first lambda takes one arg x (presumably a node). When invoked, if x is null that lambda returns null. Otherwise it returns x's Servername.

The second lambda takes two args, key and g. When invoked, if g is null, the lambda returns null. Otherwise, OrderByDescending(...) is called on it and returned.

This ... is another lambda that takes a y. When invoked, if y is null, the lambda returns null. Otherwise it returns y's Role.

Frankly, the real confusion here stems from using poor names for things. what is an 'x'? Why would i expect an 'x' to have a ServerName? Same with y. Why does y have a Role? Also, it's a bit strange to see FirstOrDefault().ToList(). FirstOrDefault is self-documenting that it can return 'default'. But then ToList() is being called on this. Which means that .GroupBy is returnign some sort of 'collection of collections'. But if that may be default, then calling .ToList() will crash. Also, grouping things only to get FirstOrDefault also seems super weird. It's doing a whole bunch of work just to throw most of it out.

I think there's a bunch wrong with that code. But the ?. isn't really the issue.

[cpplearner]

This appears like a duplicate of #1676, except that that issue proposes ?=> instead of !??. There're also #433, #444, and #842 that attempt to solve basically the same problem.

[AartBluestoke]

#1676 and #1661 (closed) are similar to this, it seems that there are several other attempts to find a solution to the problem "how do i avoid a function having to check its parameters for null all the time / deal with a function that can only accept non-null values when my thing might be null"

#433 proposes to embed within the function parameters F(?value)
links through to dotnet/roslyn#5961 , which is closed "Resolution-won't Fix" (however that was for the specific F(value?) implementation , as a subtle ? at the end of a function parameter should not change that a function is even called.
#444 is the same as #433, but proposes F(?? value)

Embedding some type of token '??' in function values leads to questions of 'are the parameters even evaluated' (explored in #444) which depend on if other parameters are null, i believe a prefix operator explicitly calling out things that are not null such as this or #1676 are most likely to receive acceptance

[bondsbw]

@orthoxerox Seems like the more appropriate shorthand operator would be >>=.

int? myInt = myString >>= int.Parse;

[YairHalberstadt]

If the pipe operator ever gets implemented then ?|> would be an obvious and intuitive operator.

So

int myInt = myString |> int.Parse;

\\becomes

int? myInt = myString ?|> int.Parse;``

[orthoxerox]

@bondsbw yes, except it's already right shift with assignment in c#

[bondsbw]

@orthoxerox Doh! Forgot about that.

Too bad some of those operators were reserved back in version 1. Even back then in C++, the bit shift operators were more well known for stream manipulation. Should have been obvious that other uses would be preferable to bit shift.

[HaloFour]

@bondsbw

Even back then in C++, the bit shift operators were more well known for stream manipulation

C++ started that by hijacking the bitshifting ops, and I'm pretty sure the result of that is exactly why C# so strictly restricts how they can be overloaded.

[bondsbw]

Understood, but my point was that they probably shouldn't have been used for bit shift at all. It's a minor use case.

Say those operators never existed in C#. Any new proposal to add them as bit shift operators into C# 8+ would probably not get off the ground.

[bondsbw]

(BTW I was mostly joking about the bind operator... C# really shouldn't try to become Haskell.)

[Unknown6656]

C# really shouldn't try to become Haskell

😢