Nullable unwrapping operator

[HaloFour]

With null parameter checking pulled from C# 11 I would like to restart the conversation but from a different perspective.

Some languages offer an operator which will forcibly "unwrap" a nullable/optional value. This operator asserts that the operand is not null and returns the underlying value, otherwise it will throw.

• Kotlin

  val name = person!!.name

• Swift

  let name = person!.name

• Rust

  let inside = drink.unwrap();

Given C# already uses ! as the null forgiving operator I believe it would be necessary to consider Kotlin's syntax.

• C# (Proposed)

void NRTs(Person? person) {
    // suppresses NRT warning, throws if person is null
    var name = person!!.Name;
}

void NVTs(int? nullableInt) {
    // effectively the same as calling nullableInt.Value, throws if nullableInt is null
    int i = nullableInt!!;
}

As for the behavior, Kotlin throws a NullPointerException whereas Swift and Rust effectively assert and fail fast. I could consider unwrapping effectively the same as calling the Value property of an NVT, I can see InvalidOperationException as being appropriate:

int i = nullableInt!!; // throws InvalidOperationException: Nullable object must have a value.

var name = person!!.Name; // throws InvalidOperationException: Nullable object must have a value.

As for how this fits with parameters, I believe that we can establish that a general operator is useful in this space and then work backwards and consider in other contexts. But at least starting at an operator establishes the kind of syntax necessary to work within a method body and with arbitrary expressions.

[canton7]

Looking at this from the other direction, I'm not sure that there's much demand for either:

1. New syntax to change the exception thrown when dereferencing a null object from NullReferenceException to InvalidOperationException
2. Shorthand syntax for Nullable<T>.Value

Kotlin/Swift/Rust/etc started off by saying that you could only forcefully unwrap a maybe-null value by using special syntax. C# didn't: we've been able to do person.Name forever. I don't think we need a second copycat syntax to do something we can already do.

[HaloFour]

It's a question of intent.

Those languages had the advantage of starting with the separate concept of nullable and non-nullable reference types, yes, but Kotlin and Swift both started on an ecosystem that didn't make that distinction and both languages are also susceptible to null/nil accidentally sneaking in. Also, you may want that gate before you attempt to dot-off of the reference, such as before you pass it along to a method:

Person? person = ...;
DoSomethingWith(person!!);

You could use ! to silence the compiler, but the problem is that you're also potentially passing null where the method is not designed to handle it and you may end up in an indeterminate state.

[jnm2]

I'd use shorthand syntax for !.Value often. More often than shorthand syntax for throwing ArgumentNullException, which was still going to be pretty often.

[HaloFour]

@jnm2

I'd use shorthand syntax for !.Value often.

It'd be nice to have consistent syntax for NVTs and NRTs also, IMO.

[orthoxerox]

Where would this operator be used? An Unwrap() (or ThrowIfNull()) extension method works just fine for NRTs, honestly.

[HaloFour]

It would be a standard operator and shorthand, but used in the same contexts. A generic extension method provided by the BCL would admittedly eliminate the need for an operator like this, however I still have interest in how this syntax could be applied in other contexts like parameters and properties.

[HaloFour]

Here's an example of such extension methods for illustrative purposes:

using System;
using System.Diagnostics.CodeAnalysis;

#nullable enable

public static class NullExtensions {
    public static T Unwrap<T>(this T? obj) where T : class {
        if (obj == null) {
            ThrowInvalidOperationException_InvalidOperation_NoValue();
        }
        return obj;
    }
    
    public static T Unwrap<T>(this T? val) where T : struct => val!.Value;
    
    [DoesNotReturn]
    private static void ThrowInvalidOperationException_InvalidOperation_NoValue() {
        throw new InvalidOperationException("Nullable object must have a value.");
    }
}

[0xor1]

Im probably ignorant, but Im not sure why you would need a new operator, if ! just threw a better null exception then it would still functionaly behave the same as it currently does, just with better exception info. Either way would be nice to have this, to save having to use NotNull/Unwrap extension methods just for brevity.

[HaloFour]

The null forgiveness operator doesn't throw exceptions, e.g.:

string? s1 = null;
string s2 = s1!; // no exception thrown

All it does is silence null dereferencing warnings, any actual exception would then come from a future dereference if the value was null.

[FaustVX]

I do understand var i = nullableObj!!;

But, I don't fully understand the following.

var name = person!!.Name

We can already do this with current syntax :

var name = person!.Name

!. already suppress the null warning and also throw if person is null.

[0xor1]

afai can tell !! isnt about suprresing warnings its about better null reference exceptions that have more context in them, it would tell you not jsut that there was a null exception but that person was null. this is helpful for thing with lots of chaining foo!.bar!.choo!.yolo if a null reference exception happens on this line at present you dont know which one was null.

[MatisseHack]

Also, object reference not set to an instance of an object isn't always the most helpful exception message (especially when chaining). I think part of the desire for this feature is to throw a better exception that indicates what is null (e.g. 'person' is null) and makes the underlying issue easier to track down.

edit: you beat me to it @0xor1 😂

[FaustVX]

Ok, Thanks for the replies :)

[DavidArno]

I feel that patterns already offer a consistent behaviour here as @KennethHoff almost highlights:

string? maybeName = TryGetName();
int? maybeAge = TryGetAge();
if (maybeName is string name)
{
    // name is definitely a string
}

if (maybeAge is int age)
{
    // age is definitely an int
}

And the advantage of this approach is that it hopefully will work with discriminated unions when they land:

int|string intOrString = GetRandomIntOrString();
if (intOrString is int i)
{
    // i is definitely an int
}

In my view, having consistency across NVTs, NRTs and DUs is far more valuable than saving a few characters by introducing a new operator that only works with the first two.

[MatisseHack]

if statements are great if you have a single nullable value (like this example), but they quickly become cumbersome when dealing with multiple (especially nested) nullable objects. At a certain point, extensive validation logic starts to distract from a method's actual purpose.

In my view, having consistency across NVTs, NRTs and DUs is far more valuable than saving a few characters by introducing a new operator that only works with the first two.

Consistency is definitely valuable, but couldn't you say the same thing about many other language features? For example ++ only works with certain types. Should its use be discouraged because it doesn't work with other addable types like TimeSpan? The proposed !! operator solves a common use case and makes code more concise just like foreach, properties, and many other existing language features that have specific use cases.

[jasekiw]

I want to reiterate again so it is very visible that the main benefit of using this syntax over the null forgiving operator is the added context of the null reference exception with the intention that you want it to blow up.

something like

foo!!.bar!!.choo!!.yolo

might compile down to

(foo ?? throw new NullReferenceException("foo is null")).(bar ?? throw new NullReferenceException("foo.bar is null")).(choo ?? throw new NullReferenceException("foo.bar.choo is null")).yolo

This would give a lot more information for someone to know exactly what variable was null. Null reference exceptions currently are very bad at this and are not fixable without adding a large amount of information to the compilation output which would slow a lot of things down. Using this syntax would allow developers to add the information where it actually matters.

I think reusing the NullReferenceException class probably makes the most sense here instead of InvalidOperationException but I'm open to reasoning on why it should be different.

What is needed to move this forward into a language design meeting?

[CyrusNajmabadi]

Nullable reference types already have a way to throw when accessing when null. You can either use . or !..

You mentioned:

the main benefit ... Is the added context of the null reference

However, that's not a language concern. That's a tooling concern.

Null reference exceptions currently are very bad at this

Then that should be fixed. So that everyone using them gets the benefit, not the handful who change to use this new Syntax.

[jasekiw]

@CyrusNajmabadi

However, that's not a language concern. That's a tooling concern.

Can you explain why you have this position and specifically why this opinion should be favored over Swift, rust, and kotlin's decision? What tooling would provide this? I am genuinely interested.

Then that should be fixed. So that everyone using them gets the benefit, not the handful who change to use this new Syntax.

I whole heartedly agree but from my research the language design team seems very against this for the inherit size and runtime costs associated with enabling it across the entire codebase. I would still enjoy a syntax to early bomb out syntax like in swift, rust, and kotlin however but I would be happy just to see null reference exceptions being better.

[CyrusNajmabadi]

Can you explain why you have this position

Because it relates to the debugging experience. Which is a tooling concern.

I would still enjoy a syntax to early bomb out

Such a syntax exists. It is .Value for nullable value types, and it is . for reference types.

That will always early bomb out.

[CyrusNajmabadi]

why this opinion should be favored over Swift, rust, and kotlin's decision

We are not trying to ape those languages. Lang features should be appropriate on their own for our language and ecosystem.

[jnm2]

That will always early bomb out.

(Except on extension methods, for reference types)