Syntactic sugar for Unsafe.IsNullRef and Unsafe.NullRef

[KyouyamaKazusa0805]

Yesterday I created a discussion (#7181) for ref var pattern matching. I found that sometimes I may use the following statement to check whether a reference is not a null ref:

ref var reference = ref obj.Property;
if (!Unsafe.IsNullRef(ref reference))
{
    // Do something playing with 'reference', or even modify its reference.
}

Because reference is not a type, it is a concept that describe a pointing relation. Therefore I cannot use a simpler way to define it (for example, using pattern matching).

If we can create a null reference simpler, or check it simpler? For example, use ref null combined keywords to define a reference to null:

ref T nullRef = ref null; // Desugar 'Unsafe.NullRef<T>()'.

Check whether a reference is null:

if (notNullRef is not ref null) // Desugar '!Unsafe.IsNullRef(ref notNullRef)'.
{
    // Play with 'notNullRef'.
}

Or even for an expression:

if (refExpression is ref var variable and not ref null)
{
}

// Equivalent to
ref var variable = ref refExpression;
if (!Unsafe.IsNullRef(ref variable))
{
}

I personally think that null ref is common to be defined as "default value" of a ref variable. Today it's difficult to detect whether a reference is a null reference, so I often use this method to check for this. But I don't think that always writing method invocation is a good and convenient.

Thank you.

[CyrusNajmabadi]

I would be opposed to any sugar into Unsafe that wasn't clearly unsafe in the C# syntax.

[FaustVX]

Maybe allow ref null only inside unsafe blocks

unsafe
{
  ref T a = ref null;
  if (a is ref null)
  { }
}
ref T b = ref GetT();
if (b is ref var c) // allowed outside unsafe
{ }

[KyouyamaKazusa0805]

Hello.

I personally don't think that Unsafe.NullRef and Unsafe.IsNullRef are unsafe methods, even though they two are put into Unsafe type. Because today C# wants to build a suitable way to use safe pointers (references). However, we may often produce some code snippet for reference checking.

For me, it is also accepted that ref null can only be used inside a unsafe block, of course. Because we can do the same thing using pointers:

unsafe
{
    ref C nullRef = ref *(C*)null; // Ok, but CS8500
}

class C;

This may be the equivalent way to get a null ref. It is unsafe code because we use pointers. C# 11 just allowed managed-typed pointers, but it will produce a CS8500 compiler warning (Managed-typed pointers). It cannot be suppressed only if we have set a #pragma warning disable CS8500 or have configured a suppression into file .editorconfig. This is too complex to be defined. I don't think getting null refs will cause CS8500 because we use a "circuitous" way to get a null ref - references are safe, but pointers aren't. I just want to get a null ref, but it cause a compiler warning, telling me that if this is a pointer, it will be unsafe. Just because the expression contains a pointer? :(

Another way is using Unsafe.NullRef<C>() to get a null ref. We may not get a compiler warning via this way, so this is an "ideal" way. However, this is also make code complex because we often write ref Unsafe.NullRef<T>(), which is a little bit long, so I suggest using ref null instead of it.

To simplify ref Unsafe.NullRef<T>(), we can use global using static or using static. It seems reasonable because it does shorten the code. However, the type Unsafe contains a method called Read, which will make me often write wrong. For example, I want to get a readonly keyword, but when I input read, Intellisense will get me Unsafe.Read instead of readonly keyword because Read has a higher priority... This is not convenient.

[svick]

Note that the CLI spec explicitly disallows null refs:

Managed pointers cannot be null.

The CLI spec also disallows quite a few things around refs that are now supported by C# and .Net (like ref fields), but I'd say those were intentional changes, allowing null ref is not the same.

It's true that the existence of Unsafe.NullRef and Unsafe.IsNullRef does give some legitimacy to null refs, but I don't think this should be taken any further, because it's not something that should be encouraged by the language.

[333fred]

@SunnieShine I made a small edit to your post to remove an extraneous ` that was breaking formatting for an entire sentence.

[TactiTac0z]

I'm pretty sure C# has been out of spec for the .Net Specification for quite a while now.

Operations on a ref variable (or indeed the recently added ref field) that are null throws an NRE as you would expect.
The runtime fully supports and regonizes "ref null" (atleast as far as I can tell)
I have used a helper to check for and assign null ref for quite a while (I was using my own for quite a while too since I wasn't aware it was in the Unsafe github package up ontil about 6 months ago)

Infact, to hammer the point in, now that we have ref fields, the default value of a ref field in a ref struct IS already "ref null"

ref struct test 
{
  public ref int x;
}
var x = default(test);
x.x++;

Is completely valid and entirely safe code right now.
And thrown NRE exactly like you would expect it to.

So at this point I see no reason to not at ref null and ´is ref null´ to the language already.
Of course if the LDM team prefers a different syntax then that I'm more than certain they will be able to figure out a good solution.
But doing nothing is pretty silly.

(I first noticed the above commented made a semilare comparison to mine above when I was done but I'm gonna send it anyway so we can get this conversation going if you guys don't mind)

Ohh hey @333fred, if you don't mind, do you know why adding 'ref null' as been delayed for so long?

[CyrusNajmabadi]

why adding 'ref null' as been delayed for so long?

Currently there appears to be:

1. a tiny number of people asking for this
2. a tiny number of people who would benefit from this
3. a reasonable workaround

So there is little motivation to do anything here compared to all the rest of the potential features we could choose from.

[TactiTac0z]

why adding 'ref null' as been delayed for so long?

Currently there appears to be:

1. a tiny number of people asking for this
2. a tiny number of people who would benefit from this
3. a reasonable workaround

So there is little motivation to do anything here compared to all the rest of the potential features we could choose from.

I suppose if I had to choose from ref null and extention types I would choose extention types.

Would fixing that you can’t use ref variables and ref parameters in local functions that are not promoted to a delegate also be on list of “tiny number of people asking for it”.
Historally I’m aware this used to be becuase struct did not support ref fields but we have ref fields now, so allowing it is basically just a green light to the Roslyn team as I see it.

You know I suppose at some point you guys could do a “ref improvement update” where multiple issues like this is fixed in one feature package like the “ref struct improvements update” we had recently.
Since there are quite a few (I suppose in your opinion minor) issues like this with ref but they add up.
Like I noticed you can declar a ref readonly variable but not a ref readonly parameter for some reason which is odd. I suppose we got ‘in’ but that is not entirely the same thing since ‘in’ is also implicit.

[TactiTac0z]

Allowing ref field’s for static and class instance members but they would only be able to point to static, class instance member or array elements would also be useful. (Or a struct instance member contained within one of those - aka not the stack of course)
Although admittedly that would be rather niche and would require runtime changes so that is fair.