Proposal: inverted null-coalesce operator ?!

[niklaskallander]

I'd very much like to see a new operator in C# that kind of does the opposite of the null-coalesce operator ?? (like the null propagation operator ? but still different).

Usage example:

string possibleIntInput = ...

int? possibleIntValue = possibleIntInput ?! int.Parse(possibleIntInput);

If possibleIntInput is null, then null is returned otherwise an attempt is made to parse it (or whatever other thing you'd want to happen as long as the left-hand object/value is not null).

Then you could avoid less expressive code like:

string possibleIntInput = ...

int? possibleIntValue = possibleIntInput != null
    ? int.Parse(possibleIntInput)
    : null;

dotnet/roslyn#5445 proposes forward piping with null propagation behavior, and I would love being able to write something like this (it's so expressive and functional-like):

string possibleIntInput = ...

int? possibleIntValue = possibleIntInput ?> int.Parse;

but I don't just want forward piping, I also want a syntax for either null or {whatever code} (that returns an object/value of whatever type is expected by the context).

What do you think?

[Unknown6656]

I personally think, that it is a wonderful idea, I do however dislike the token ?!, as it is not intuitive (IMO) and could possibly create some confusion with a ternary operator followed by a logical not: a ? !b : c =/= a ?! b : c.

I would like to see the pipe-operator |> and its null-coalescent partner ?> implemented, as I love functional programming and personally think, that C# could be more powerful in this direction.

[niklaskallander]

Ah, never thought of that scenario, nice!

What token to use is of no big importance to me though. You may be able to flip it around to !? instead but I'm not convinced you'd find that more intuitive.

My initial thought of ?! was to build on the null propagation syntax but somehow indicate a "hand-over" (or whatever one would want to call it) instead of a continued use of the null-checked object (as in the case of null propagation).

I like ?> but I think that token fits better for a forward piping scenario.

How about ?: ?

[qrli]

Using existing features:

string possibleIntInput = ...

int? possibleIntValue = possibleIntInput?.ParseInt32();

static int? ParseInt32(this string str) { ... }

[qrli]

Or with a generic helper function:

static TResult Do<TInput, TResult>(this TInput input, Func<TInput, TResult> func)
{
  return func(input);
}
string possibleIntInput = ...
int? possibleIntValue = possibleIntInput?.Do(int.Parse);

[niklaskallander]

Yes, it is possible to "overcome" this using extension methods. However, I don't find extension methods as expressive, and, if I were to start passing delegates around I'd have to check them for null too.

It's not ideal!

[iam3yal]

Just a crazy idea but what do you think about the following syntax:

possibleIntInput !! int.Parse(possibleIntInput)

[niklaskallander]

I'm all for it as long as it works with the rest of C#! (:

[iam3yal]

Yeah it's a bit tricky. 😄

[orthoxerox]

int? possibleIntValue = 
from x in possibleIntInput
select int.Parse(x);

The only problem is, this doesn't work because nullable value and reference types don't mix until/unless we get nullable reference types in C# vNext.

[niklaskallander]

Also, string is an IEnumerable<char> so I don't think it would work particularly well at all? Am I missing something?

[orthoxerox]

@niklaskallander Yes, but is string? one?

[niklaskallander]

@orthoxerox Again, am I missing something?

[orthoxerox]

@niklaskallander it's possible to implement Select and SelectMany on nullable types that unwrap the inner value for processing.

[ufcpp]

You can do nearly the same with an extension method:

using System;

static class Extensions
{
    public static TResult Apply<T1, TResult>(this T1 x, Func<T1, TResult> f) => f(x);
}

class Program
{
    static int? F(string s) => s?.Apply(int.Parse);
}

[niklaskallander]

@ufcpp Using extension methods has already been proposed by @qrli a few comments ago, and as I replied to his proposal: Extension methods are not as expressive and passing delegates gives you more stuff to null-check.

It's not ideal!

@orthoxerox Now I follow, thanks for explaining! Unfortunately, as with all other proposals using extension methods (which this also is but with some sugar on top), it's not as expressive and the linq syntax is too verbose for my liking.

[iam3yal]

@niklaskallander Proposed new language features should be discussed at the C# repo so you may want to close this and open a new issue there.

[v-kydela]

If we're going for syntactic sugar then piping would surely be ideal because the reverse-coalescing would still require you to provide the input twice

[drdamour]

I often have the pattern of
identity.HasPermissionX ? new X(...) : null and new X(...) is usually some multiline db query linq statement and that :null get's thrown at the end.

with this i could change it to
identity.first(p > p.name == 'can do x') ?! new X(...)

so it'd be cool if the left hand side could treat false as nully (or null as falsey)

[breket]

I need this feature. But my proposition about alias is !?? like opposite to ??
car.vendor = vendorId !?? getVendorById(vendorId)

This means: when vendorId is Null then assign Null to car.vendor, otherwise get vendor by that vendorId.

You can also write the same using
car.vendor = vendorId == null? null: getVendorById(vendorId)
but my first examlpe looks better =)

[CyrusNajmabadi]

!?? is already legal syntax in use today

[breket]

!?? is already legal syntax in use today

and what does it do? My VS does not recognize it

[CyrusNajmabadi]

and what does it do? My VS does not recognize it

x!??y would suppress NRT annotations on 'x' (!), and then perform the coalescing operation (??).

[ChristopherHaws]

This is possible in JavaScript using the && operator. Would love to see something similar added to C# :)

console.log(null && "Foo") // null
console.log({} && "Bar")   // Bar

I would say ?: makes the most sense (since if your remove the null's and whitespace from foo is null ? null : "foo" that is what is left) but it already has a different meaning in many other languages which might be confusing.

[mrwensveen]

I like &&. It could be defined as: "Returns the left-hand value when it is the default value for that type, otherwise returns the right-hand value."

That way it maintains compatibility with its current (Boolean) meaning, while also providing the inverted null-coalesce meaning.

Console.WriteLine(null && "Foo"); // null (empty line)
Console.WriteLine("Foo" && "Bar"); // Bar
Console.WriteLine(false && true); // False
Console.WriteLine(true && false); // False (semantically unchanged)
Console.WriteLine(0 && 1); // 0
Console.WriteLine(1 && 2); // 2

Where in JavaScript the behavior is defined by truthyness, in C# it could be defined by default-ness.

[v-kydela]

But 0 is both falsey and the default, so why would 0 && 1 equal 1 in either of those cases?

[mrwensveen]

Oops, you're right. Fixed.

[iricigor]

Bumping this up.

Here is one use case example (presuming !? is new operator):

return FirstName + (MiddleName !? $" {MiddleName}") + ' ' + LastName;

[drdamour]

Bumping this up.

Here is one use case example (presuming !? is new operator):

return FirstName + (MiddleName !? $" {MiddleName}") + ' ' + LastName;

Isnt
‘’’
MiddleName ?? “”
‘’’

effectively the same there?

[v-kydela]

@drdamour - Try it. You may notice there's an extra space when there's no middle name.

[mrwensveen]

Bumping this up.
Here is one use case example (presuming !? is new operator):

return FirstName + (MiddleName !? $" {MiddleName}") + ' ' + LastName;

Isnt
‘’’
MiddleName ?? “”
‘’’

effectively the same there?

This is getting a little of topic. But, no, that's not the same because of the space @iricigor wants to insert a space before MiddleName if it isn't null. His example isn't the best example because there a thousand other ways to solve that problem, but that's not the point.

PS. Here's one way: return string.Join(" ", new [] { FirstName, MiddleName, LastName}.Where(s => !string.IsNullOrEmpty(s)));

[drdamour]

@drdamour - Try it. You may notice there's an extra space when there's no middle name.

Ah yeah, missed the space. Nice example

[ber-sma]

Although there have been mentions of extension methods here, and it was said that this proposal is focused on a language feature, I would like to add another workaround. What we use extensively in our code base is a set of extension methods that is specifically made for checking the nullable for null and applying a transformation function on non-null values. This works because extension methods can also be called for a null "receiver".

string possibleIntInput = ...
int? possibleIntValue  = possibleIntInput.GetOrNull(int.Parse);

The solution is far from perfect, however, due to the need for all combinations of receiver and transformed type struct/class constraints. Also, not all methods can share the name GetOrNull because the compiler cannot distinguish them just on the constraints (yet?).

public static TResult GetOrNull<TValue, TResult>(this TValue value, [InstantHandle] Func<TValue, TResult> get)
    where TValue : class
    where TResult : class {
    if (value == null) {
        return null;
    } else {
        return get(value);
    }
}

public static TResult? GetValueOrNull<TValue, TResult>(this TValue? value, [InstantHandle] Func<TValue, TResult> get)
    where TValue : struct
    where TResult : struct {
    if (value == null) {
        return null;
    } else {
        return get(value.Value);
    }
}

(other combinations omitted for brevity)

[LarryWMSN]

It appears that the workaround suggestions depend on only the original evaluated object getting passed. I believe this condition would break them:

var newObjects = oldObjects !? MakeNewObjects(otherObjects, someVariable, anotherVariable);

Instead of:

var newObjects = oldObjects is null ? null : MakeNewObjects(otherObjects, someVariable, anotherVariable);

In this case we only want newObjects if oldObjects is not null. Because MakeNewObjects returns a collection of newObjectType, if oldObjects is null then newObjects would be a null List of newObjectType.