The lifetime of a ref return should not be same to the ref struct itself

[2A5F]

public ref struct Foo1<T>(ref T[] arr)
{
    public ref T[] arr = ref arr;       // even T[] arr = arr; why?
    public ref T Ref() => ref arr[0];
}

public static class Foo2<T>
{
    public static ref T Some(T[] arr)
    {
        var a = new Foo1<T>(ref arr);
        return ref a.Ref();
                // ^ error CS8352: Cannot use variable 'a' in this context because it may expose referenced variables outside of their declaration scope
    }
}

UnscopedRef cannot be marked on the return value

https://sharplab.io/#v2:EYLgtghglgdgNAFxFANgHwAICYCMBYAKEIwGYACAJwFMAzMgZwQoFcBjBMgMQHtucAeACoA+ABTU6ggNoBdMhAoUAlIQDehMprKky0uQopkAvPMUBuDVp0TdZAEq1RS48Mq1TFKQAYZFggF9CYnIMHAA2bSwuXiwhYTVLTR1QiJtBMgBlbjAqUT0PFQItMnUi4q0ANwV5YzIYKgB3aL448XcDJT9yqwB2NzoIADoHGicurUCAwiA

---

Note: Can bypass by Unsafe.AsRef

[jaredpar]

Lets track this out

var a = new Foo1<T>(ref arr);

This is passing ref arr to a ref struct constructor. This is a local and the ref-safe-context of a local is the current method. That means that a has a safe-context of the current method. It cannot be returned. This in turn means that any ref-like values that come from a are similarly restricted to the current method. This is why the compiler correctly errors on return ref a.Ref().

In this particular case my question would be what is the reason for having ref T[] as an argument? That is the root of the complications here.

[jaredpar]

public static ref T Ref<B>(ref B box) where B : IBox<T>

The problem with the sample is the ref on the parameter here. Because this is unannotated and the method is a ref return the compiler has to assume that it can participate in the return. Basically compiler has to assume that ref T could be pointing into box.

This code sample does not do this though. Based on context I believe the ref passing style is to either to preserve mutations or for performance. Given that the ref is not returned as ref then have the compiler enforce that with scoped

public static ref T Ref<B>(scoped ref B box) where B : IBox<T>

Once the compiler knows that the ref parameter can't be returned by ref then the sample compiles just fine:

sharplab

If have lifetime mark like rust

That is roughly what scoped is doing here. It gives the lifetime of the ref the same lifetime as locals in the current method.

[2A5F]

shit complex code, this is not a deliberately complex example, it is still a simplification of the actual code

public readonly ref struct RefBox<T>(ref T Ref)
{
    public readonly ref T Ref = ref Ref;
}

public interface IBox<out R> where R : allows ref struct
{
    public R Ref();
}

public ref struct Box<T, A> : IBox<RefBox<T>>
{
    public ref A data;
    // array or class, any $heap lifetime
    public T[] arr;
    // ... large struct
    
    public RefBox<T> Ref() => new(ref arr[0]);
}

public static class Foo<T>
{
    // if scoped
    // error CS8352: Cannot use variable 'scoped B box' in this context because it may expose referenced variables outside of their declaration scope
    public static R Ref<B, R>(B box) 
        where B : IBox<R>, allows ref struct
        where R : allows ref struct
    {
        // ... some code
        return box.Ref();
    }
    
    public static ref T Some<A>(T[] arr, A data)
    {
        Box<T, A> box = new() { arr = arr, data = ref data };
        // ... some code
        var r = Ref<Box<T, A>, RefBox<T>>(box);
        // ... some code
        return ref r.Ref;
        // error CS8352: Cannot use variable 'r' in this context because it may expose referenced variables outside of their declaration scope
    }
}

godbolt

(sharplab currently does not support net9

---

actual code
gist

[jaredpar]

Think you can reduce that problem to the following code:

ref struct S1; 
ref struct S2(ref int i)
{
    S1 Get() => default;

    S1 Test()
    {
        int i = 0;
        var s2 = new S2(ref i);
        return s2.Get();
    }
}

Essentially when a ref struct is returned from a ref struct the compiler assumes it must capture ref fields. This is a limitation of what you can state with the available lifetime features in C# today.

In order to allow this pattern we'd need to effectively represent that the this inside an instance method can't escape any state. Basically we'd need to have ref scoped and make it work for the implicit this in a struct instance method. That would get the desired behavior here.

[2A5F]

Will there be a proposal or something?

[jaredpar]

The ref scoped proposal I linked is what we would need here

https://github.com/dotnet/csharplang/blob/main/proposals/expand-ref.md

It doesn't explicitly cover this case but it's a fall out from the parameters work.