[Proposal] Allow out ref parameters methods.

[itsBuggingMe]

Motivation

Many APIs written in C# use some form of a bool TrySomething(out T value) pattern, where the return value represents success or failure. This pattern especially ergonomic to use, especially since you can concisely integrate them into if statements or ternaries.

string ageString = "6";
if (int.TryParse(ageString, out int age))
{

}

However, the moment the success value is a ref, the pattern breaks. The workaround is to return a ref T, and an out bool instead to indicate success or failure.
A a contrived example, consider a ref int TryGetAt(this int[] arr, int index, out bool exists) extension method implemented on an array.
The usage would be:

int[] arr = [1, 2, 3, 4];
ref int value = ref arr.TryGetAt(arr, out bool exists);
if (exists)
{

}

In fact, the CollectionMarshal.GetValueRefOrAddDefault() method does just that.
This is quite a lot worse to look at and arguably less readable.

Potential implementation

I believe this feature can be implemented purely through lowering. You can already achieve a similar syntax through wrapping a ref with a ref struct.

if (TryGetAt([1, 2, 3], 2, out Ref<int> value))
{
    ref int valueRef = ref value.Value;

    //now, you can do whatever with the ref as normal
    valueRef = 0;
    Console.WriteLine(valueRef.GetType());
    //or use the wrapper directly
    value.Value += 6;
    Console.WriteLine(value.Value.GetType());
}

bool TryGetAt(int[] arr, int index, out Ref<int> value)
{
    if ((uint)index < (uint)arr.Length)
    {
        value = new Ref<int>() { Value = ref arr[index] };
        return true;
    }

    value = default;
    return false;
}

internal ref struct Ref<T>
{
    public ref T Value;
}

With out ref parameters, the code would be simplified like this:

if (TryGetAt([1, 2, 3], 2, out ref value))
{ 

}

bool TryGetAt(int[] arr, int index, out ref value)
{
    if ((uint)index < (uint)arr.Length)
    {
        value = ref arr[index];
        return true;
    }

    value = ref Unsafe.NullRef<int>();
    return false;
}

Pros

1. Shorter code
2. Better readability
   I also believe this to be a natural extension to the existing ref features

Cons

1. It could be confusing, since it is technically a T**. An out is already a form of a ref, after all.
2. This pattern isn't too too common
3. There isn't really an easy option of a default value to a ref

[huoyaoyuan]

As low-level unsafe methods, the established practice is to return Unsafe.NullRef at the ref return, instead of assigning an additional boolean value. This maximizes performance to align with the goal of using ref. An example is CollectionsMarshal.GetValueRefOrNullRef.

[itsBuggingMe]

I am more concerned about the times were a ref is used but in a not low-level unsafe context - I don't want the user to have to use Unsafe.IsNullRef to use basic functionality of a library.
I do agree though that a lot of the times when a ref return is used, its for high performance reasons.

[ufcpp]

The TryGetValue problem is solved by NullRef, but the multiple return values problem cannot.

[itsBuggingMe]

I would also like to note that this would set the groundwork for some version of ref tuples e.g. (ref int x, ref double y).
Any version of ref tuples that supports deconstruction will also need out refs.

[huoyaoyuan]

The groundwork isn't set at C# level. It needs to be set in CLR type system.

[jaredpar]

You can already achieve a similar syntax through wrapping a ref with a ref struct.

One of the main issues with a Ref<T> lowering approach is that it ends up limiting out ref to types that can satisfy T. That means it will not work for ref struct, pointers, etc ... It will be incomplete.

The workaround is to return a ref T, and an out bool instead to indicate success or failure.

This problem has come up already in the runtime and they chose a different approach. Effectively have a ref return where Unsafe.NullRef is used to check success / fail. Example is CollectionMarshal.GetValueOrNullRef. Yes it's a bit different to use Unsafe.NullRef but ref returns is generally considered a bit of an advanced scenario.

[itsBuggingMe]

I think the generic constraint issue can be solved by explicitly generating a struct with a field of the specified type.

internal unsafe ref struct Ref
{
    public ref int* Value;
}

I'm slightly worried about this bloating the DLL size, but there is also already a precedent to do generate specialized types just for languages features - caching lambdas and generating closures - so it should be fine?

About using Unsafe.NullRef instead, my main concern with directly returning a null ref at the ref return is that it requires the user to understand how to use the Unsafe class. It also does not solve the issue of multiple ref returns.

[jaredpar]

I think the generic constraint issue can be solved by explicitly generating a struct with a field of the specified type.

That struct though cannot be internal, it must be at least as accessible as the method in question. That means in many cases it becomes part of the public API surface area of your project.

but there is also already a precedent to do generate specialized types just for languages features - caching lambdas and generating closures - so it should be fine?

None of these impact the public API surface of the assembly.

About using Unsafe.NullRef instead, my main concern with directly returning a null ref at the ref return is that it requires the user to understand how to use the Unsafe class.

True but that is a deliberate choice that language + runtime made in this area. Even your proposal though has to solve this problem. Cause in the case of returning false you need to fill in a value for the out ref and that is likely to be something along the lines of Unsafe.NullRef.

It also does not solve the issue of multiple ref returns.

Thus far there hasn't been an API for which this was a problem. Or enough of one that it needed a solution.