API proposal: Unsafe.NullRef, IsNullRef

[jkotas]

Proposed API

namespace System.Runtime.CompilerServices
{
    public class Unsafe
    {
        public bool IsNullRef<T>(ref T);
        public ref T NullRef<T>();
    }
}

ref cannot be null pointer in C#, but it is perfectly valid in IL. ref containing null pointers are useful for low-level optimizations. For example, dotnet/coreclr#27195 uses them to make Dictionary lookups about 10% faster. There are several other examples in the .NET Core framework where we have used ref containing null pointers.

The Unsafe class does have building blocks that allow operations on null ref pointers (e.g. Unsafe.AsPointer<T>(null) creates null ref), but it obfuscates the intent and it is not as straightforward and lean as it can be. The proposed APIs will make it easier.

[jkotas]

cc @GrabYourPitchforks @benaadams @VSadov

[GrabYourPitchforks]

Bwahaha, this lives! 😈

Though upon further thought I'm curious as to whether for usability's sake it would be better to take "ref" instead of "in". I'm wondering if there will be pits of failure where folks pass non-refs to this method, the compiler fixes up the call site to create a reference to the copied local, and the method always returns false.

[jkotas]

it would be better to take "ref" instead of "in"

Agree.

[VSadov]

I think it should take ref.

ref guarantees aliasing.

in allows you to pass rvalues by passing a ref to a copy . There is a little point to test those for null. It would be most likely a bug.

in allows to pass lvalue of TDerived type by passing a ref to a copy. You would get an NRE instead of true

Basically - most cases that in enables you do not want enabled.

[tannergooding]

At the same time, in is more appropriate because it does not mutate the ref and not taking in forces users who have a readonly ref to use ref Unsafe.As(in value)

An analyzer would likely be sufficient to catch the issues of passing an rvalue etc.

[GrabYourPitchforks]

API review - This really should be in from a purity perspective, but should sit down with language folks to figure out exactly what pitfalls might exist and whether the language itself could be evolved to address any concerns. I'll punt this back to myself.

[jkotas]

FWIW, there are two reasons why this should take ref:

• Consistency with the existing APIs: All existing S.R.CS.Unsafe APIs for ref pointer arithmetic take ref.
• Pit of success: in makes it easy to introduce accidental aliasing as pointed above.

[tannergooding]

Consistency with the existing APIs

Many of the APIs were added before in existed (C# 7.2) and it causes issues anytime you want to work with readonly references as it requires you to convert using ref T Unsafe.As<T>(in T). Not only does this add another API call but it strips the readonly from the ref which can make code harder to follow/maintain. There are a number of other APIs (not on Unsafe) where this can also be problematic (one example is Volatile.Read) but for which we can't change due to back-compat (the C# language doesn't allow in methods to be called using the ref keyword, even though it is narrowing, so it is source breaking).

in makes it easy to introduce accidental aliasing as pointed above.

This is true for any usage of in and is a side effect of the compiler allowing rvalues. There exists some well known analyzers (such as ErrorProne.NET) which help avoid these issues.

Personally, I would much rather have an analyzer enabled that calls out places where I may be doing inefficient things than have to insert the equivalent of const_cast all over the place.

However, maybe as an alternative, we could have both IsNullRef(ref T) and IsNullRefReadonly(in T) ?

[jkotas]

it causes issues anytime you want to work with readonly references as it requires you to convert using ref T Unsafe.As<T>(in T)

I have written quite a bit of code against S.R.CS.Unsafe and I have not found this to be a nuisance. I find the unsafe byref-arithmetic with ref to be more readable than with readonly ref/in.

However, maybe as an alternative, we could have both IsNullRef(ref T) and IsNullRefReadonly(in T) ?

Yes, this sounds better to me.

[broudy3]

What about out reference? Could the null check be added also for that? Something like:

public static bool IsNullOut<T>(out T value)
{
   SkipInit(out value);
   return IsNullRef(ref value);
}

example : IsNullOut(out NullRef<int>());

[GrabYourPitchforks]

@broudy3 what's the scenario for caring about 'out'?

Edit: some further thoughts - methods that accept 'out' parameters basically have a contract "I'll write to this address before the method returns." It would be a caller error to pass null for these addresses, akin to saying "in the x64 calling convention, I'm expecting a struct return value but passing nullptr for rcx." The method should expect to AV upon returning.

[tannergooding]

That's really the C# contract however, not necessarily the IL contract. There are plenty of native methods, for example, which take a T** result where the other inputs are validated or special values are looked up if result is null and otherwise they perform the operation as normal.