[Proposal] Extending the 'ref' keyword. (ref null, ref comparison)

[Neo-Ciber94]

Extending the 'ref' keyword (ref null and ref comparisons/equality)

One of the current limitations of the ref keyword if that can't be assigned to null but there are cases where returning 'null' is convinient.

One of the solutions I suggest is just allow ref to be assigned to null.

ref int a = ref null;

And also allow a way for null checking.

if(ref a == ref null)
{
      //Do something
}

Ok but, you are just adding more NullReferenceExceptions to C# . . .

True, but these can be solve allowing 'ref' to be declared as nullable and non-nullable.

ref? var xyz; //Can be null.
ref var zyx; //Cannot be assigned to null.

Usage examples:

ref? int a = ref null; //Ok
ref? int b; //Ok, is null by default.

ref int c = ref null; //Error
ref int d; //Error

int value = 5;
ref int e = ref value; //Ok

const int AnimeIsReal = 42;
public static ref? int SomeMethod(ref int value)
{
      if(value > AnimeIsReal)
      {
            return ref null; 
      }

      value + 5;
      return ref value;
}

And also ref comparisons/equality.

if(ref a == ref null)
{
   //Do something
}

if(ref e == ref null) //Error 'e' cannot be null
{ 
   //Do something
}

When comparing ref? is not necessary specified if is nullable.

if(ref? a == ref null) //Its correct but not necessary.
{
   //Do something
}

if(ref e == ref null) //Error, 'e' was declared as non-nullable.
{
   //Do something
}

Also the ref keyword can be used for compare the address of the value being passed by reference.

int valueA = 10;
int valueB = 5;

ref int a = ref valueA;
ref? int b = ref valueB;
if(ref a == ref b) //If 'a' address is equals to 'b' address.
{
   //Do something
}

if(ref a > ref b) //If 'a' address if greather than 'b' address.
{
   //Do something.
}

//In these cases I'm assuming 'ref null' == '(void*)0L'
if(ref a > ref null) //Must always returns true.
{
   //Do something
}

if(ref b > ref null) //Could be true.
{
   //Do something
}

• Related:

#497
#1201

[HaloFour]

ref by itself would already indicate a non-nullable reference. There's no need for a ! suffix. This is the same tactic being used for nullable references for reference types, where string is non-nullable and string? is nullable. Given that ref is already pervasive throughout the language and is already assumed to not be null to allow it to become obliviously null would be quite dangerous.

I can't find the comments at the moment but for what little feedback I've seen from the team on this subject they haven't seemed that interested in adding yet another null reference vector into the language. If you want references without the safety and guarantees afforded by ref why aren't unsafe and pointers enough?

[Neo-Ciber94]

@HaloFour

This is the same tactic being used for nullable references for reference types, where string is non-nullable and string? is nullable.

Could be the same for ref , allow it be nullable solves the cases where you want return 'null' but its not possible when using ref.

If you want references without the safety and guarantees afforded by ref why aren't unsafe and pointers enough?

The problem with pointers if that are limited to managed types.

[HaloFour]

@Neo-Ciber94

Could be the same for ref , allow it be nullable solves the cases where you want return 'null' but its not possible when using ref.

If ref? were added you would use that to return null instead. There's no need to extend the support to ref, where it is assumed that it won't be null. If ref could all of a sudden be null then 18 years worth of ref code would be compromised as none of it expects null.

[Neo-Ciber94]

@HaloFour

If ref could all of a sudden be null then 18 years worth of ref code would be compromised as none of it expects null.

Correct, but I don't propose to break existing code that use ref rather add ref? to be aware that the reference could be null.

Here just a case where you actually want return a ref null.

public static ref? Employee Find(int ID)
{
    for(int i = 0; i < employees.Length; i++)
    {
         ref var p = employees[i];
         if(p.ID == ID)
            return ref p;
    }
     
    return ref null;
}

ref? Employee e = ref Find(42);
if(ref e != ref null)
{
    //Do something
}

[AustinBryan]

@Neo-Ciber94

I don't propose to break existing code that use ref rather add ref? to be aware that the reference could be null.

This conflicts when you said:

Also ref without constrain means that can be either nullable or non-nullabe.

Which I'm not sure what that even means. It either is nullable, or it isn't. Being "either" nullable or nullable, would mean it could have a value, or it could be null, which is literally just nullable.

Adding ref! is the same thing as the current ref so there's no point in having it to do the exact same thing. Also, the behavior of ref should not be changed by any means as that can and will break existing code with no gain, and it will be the same as ref?.

[svick]

@Neo-Ciber94

While I agree that nullable ref would be useful in that situation, it's also fairly easy to work around by creating a simple struct that can create the ref:

public struct ArrayRef<T>
{
    T[] array;
    int index;
    
    public ArrayRef(T[] array, int index) => (this.array, this.index) = (array, index);
    
    public ref T Get() => ref array[index];
}

public static ArrayRef<Employee>? Find(int ID)
{
    for(int i = 0; i < employees.Length; i++)
    {
         ref var p = ref employees[i];
         if(p.ID == ID)
            return new ArrayRef<Employee>(employees, i);
    }

    return null;
}

Sure, ArrayRef<T>? is less flexible and more cumbersome to use than ref? T would be, but not by that much. So I think adding nullable ref just for code similar to the above would not be worth it.

[Neo-Ciber94]

@AustinBryan

Which I'm not sure what that even means. It either is nullable, or it isn't. Being "either" nullable or nullable, would mean it could have a value, or it could be null, which is literally just nullable.

Sorry, my error, english is not my main language, It's fixed.

My post was also update thanks to the discussion:

• ref stay as always, what eliminating the needed of ref!.
• ref? means that the reference can be null.

[Neo-Ciber94]

@svick It's a way but the benefits of returning by ref are lose and more when a struct is being returned.

[ufcpp]

so what's different from #497?

[ufcpp]

FYI

using System;

static class Program
{
    unsafe static void Main()
    {
        Span<int> span = default;

        fixed (int* p = span)
        {
            Console.WriteLine((long)p); // 0 (null pointer)
            // This means that `span.GetPinnableReference()` returns null as `ref int` type.
        }
    }
}

[svick]

@Neo-Ciber94

It's a way but the benefits of returning by ref are lose and more when a struct is being returned.

What benefits are lost? You can still write directly to the struct, as if it was returned by ref (because it is being returned by ref from the ArrayRef<T>.Get() method). And you're not copying the whole struct.

[evilguest]

Ok, I can imagine a possible case where null ref local might have some sense:

public void SaveNumber(int number)
{
  ref int target = ref Null<int>();
  if (IsNull(ref target))
    TryGetThreadLocalStorage();
  if (IsNull(ref target))
    ref target = ref TryGetInstanceStorage();
  if (IsNull(ref target))
    ref target = ref this._instanceStorage;
  target = number; 
}

I.e. we treat target as "the place to store stuff", and null there indicates "no, we have no place to store stuff".
This is a dangerous approach, since regular code that deals with ref structs doesn't expect any Nulls there, so I'd limit the scope of nullable ref propagation as much as possible.
If you feel compelled enough to use this dangerous approach within your code, then don't wait for the community to tweak the language/platform/class library. Go ahead:

public static unsafe ref T Null<T>() where T : unmanaged => ref *(T*)null;
public static unsafe bool IsNull<T>(ref T reference) where T:unmanaged
{
  fixed (T* p = &reference)
    return p == null;
}

[evilguest]

The same approach can be extended to cover the reference equality:

public static unsafe bool RefEquals<T>(ref T left, ref T right) where T: unmanaged
{
  fixed(T* l = &left, r = &right)
    return l==r;
}