Operator to assign left side only if right side is not null, e.g: =??

[EskeRahn]

I often in C# miss the 'opposite' operator of

  ??=

The obvious syntax would be

  A  =?? newAvalue;

As a more readable way to write

  if (newAvalue is not null and var temporaryA) A = temporaryA;

(above edited as suggested by @DavidArno)

Or the dirty, but easier to read, variant (that superfluously calls a getter and setter if the new value is null)

  A = newAvalue ?? A:

Especially useful for e.g. a constructor with optional arguments, where the elements in the class has default values already.
And we only want the defaults overwritten when we actually provide a value for it;

Example

class MyClass {
    int Foo {get; init;} = 123;
    int Bar {get; init;} = 1234;
    public MYClass() { }
    public MYClass(string something, int foo=432, int? bar=null) {
        Foo = foo;
        Bar =?? bar;
    }
}

[siegfriedpammer]

I think the claim "more readable" is disputable.

[EskeRahn]

I think the claim "more readable" is disputable.

if =?? is not considered "more readable" than the expanded version, the same argument could be used against "??="

[EskeRahn]

The point is obviously the functionality not the specific characters used for the operator, anyone reachable with an ordinary keyboard would be fine with me...

[DavidArno]

if =?? is not considered "more readable" than the expanded version, the same argument could be used against "??="

I disagree. I actually find x ??= y far clearer than the old x = x ?? y

The first reads as "assign y to x if x is null". The second reads as "assign x to itself unless its null, in which case assign y to x", which seems a nonsense thing to do. Whilst they clearly do the same thing in reality, the ??= just makes more sense as a way of expressing things.

[EskeRahn]

I disagree. I actually find x ??= y far clearer than the old x = x ?? y

Also remember that
x = x ?? y
always calls the setter, the x ??= y form can optimize and only call when needed, and a setter may be a complex thing, and not just a plain store.

[orthoxerox]

and a setter may be a complex thing, and not just a plain store

There's a special place in the afterlife for those who write setters or getters with observable side effects.

[EskeRahn]

Indeed! He he.
But it does not HAVE to be a side-effect as such to be time-consuming. Say you are low on ram and have existing software working with a large list of items with a huge property, then a compress/decompress setter/getter might be tolerable quick-fix despite the performance hit.

[DavidArno]

There is an existing mechanism for doing this that is genuinely more readable:

if (newAvalue is not null and var temporaryA) A = temporaryA;

There is a case that newAvalue is not null and var temporaryA ought to be expressable as newAvalue is not null temporaryA, but that's a different topic. Whilst longer than =??, it's far more expressive of the intent in my view. And it already exists.

And regarding your code example with optional parameters, the simple solution is use overloads rather than optional parameters:

class MyClass 
{
    int Foo {get; init;} = 123;
    int Bar {get; init;} = 1234;
    
    public MyClass() { }

    public MyClass(int foo)  => Foo = foo;
    
    public MyClass(int foo, int bar) : this(foo)  => Bar = bar;
}

[EskeRahn]

Thanks for the clearer code example. Edited in OP.

And regarding your code example with optional parameters, the simple solution is use overloads rather than optional parameters:

Indeed in this particular simple example it can be done with overloads.
In your example, what if you also want to be able to set Bar only? Here overloads can not do the trick due to same type.
In general with multiple optional parameters it quickly becomes a mess (or even impossible), with all combinations.
Unfortunately merely two optional of the same type is enough for overlads to not being able to solve it.

But this is not limited to function calls/constructors, as late as yesterday I needed it for reading from a json-file into my own flat structure, (a dictionary), where tags may or may not exist.

Currently I use an action that does it, obscuring how simple the task I'm doing is
MyDict["Foo"] =?? ExtractingValueForFoo();
would be clear.

Both of
SetMyDictEntryIfValNotNull("Foo", ExtractingValueForFoo());
if (ExtractingValueForFoo() is not null and var valueForFoo) MyDict["Foo"] = valueForFoo;
are convoluted to read, IMHO.

[Serdan]

Below is equivalent, right?

if (newAvalue is { } temporaryA) A = temporaryA;

var matches everything, but {} only matches non-null.

[DavidArno]

@Serdan,

Absolutely that is equivalent. THe jury is out on whether it is more readable though. It's shorter for sure, but there's a lot of folk that dislike it and I find it best to avoid it. But that's really personal opinion.

[Serdan]

Hmm, right. I think people are being weird about that. Braces in a pattern unambiguously means "object instance".

It's nice to have options, though. 🙂

[NonerDude]

Everyone dislikes the suggestion yet you find many people online asking for a simple solution for just that, It's readable and useful.
Perhaps this syntax is less beginner-friendly (although JS never was when it comes to syntax), but so is i++ and ++i;

[EskeRahn]

Yes the syntax suggested might not be optimal, but the functionality would be useful in many circumstances, where you want something to optionally overrule.
Another example is when you got a value that you want to be able to overrule by an environment setting - if and only if available.

[DES-Destry]

What about syntax like that?

sureNotNull <<= possibleNull;

Alternative of

sureNotNull = possibleNull ?? sureNotNull;

sureNotNull duplicating can lead to possible errors, when you have to set a lot of values with the same type, just due to typo.

[EskeRahn]

The operators <<= and >>= are already in use for bit-shifting so would be somewhat confusing.

And strictly I would not require that the left side had a non-null value. But if the right side was not null it would override.

[Guiorgy]

The proposal to use =?? as the syntax was because there's already a similar one (??=). I don't think introducing a completely different one makes sense, especially ones that are already in use, as EskeRahn pointed out.