Proposal: Allow struct members to return ‘this’.

[Jeremy-Price]

I propose the restriction that struct members cannot return references to ‘this’ be dropped. The analysis done at call sites is sufficient to determine validity if struct instance methods are treated as having implicit ‘ref this’ parameters.

Consider the declaration of the method X below, which complains: “struct members cannot return ‘this’ or other instance members by reference.” The concern is that the ‘this’ reference might outlive the lifetime of the struct on the stack.

struct Foo
{
    public ref Foo X() => ref this;
}

But the method X is equivalent to:

public static ref Foo X(ref Foo foo) => ref foo;

Which is a valid method declaration. Of course, this declaration doesn’t allow the ‘foo’ reference to outlive its lifetime, because we can’t write things like:

Foo foo = new Foo();
return ref X(ref foo);

Even though these two ‘X’ methods are equivalent, the prohibition on returning ref this and of returning ref X(ref foo) are not equivalent.

For example, the below is well-defined behavior, but is not allowed by C#:

struct Foo
{
    ...
    public ref Foo Current => ref this;
}

foreach (ref Foo foo2 in foo)
{
    
}

Just as above, the ‘Current’ property is semantically equivalent to

public static ref Foo Current(ref Foo foo) => ref foo;

and because the foreach statement won’t cause the ‘foo’ reference to escape foo’s lifetime, this should be allowed.

[OyasumiLad]

If this behaviour is crucial to your project and you don't mind some unsafe code you can just point to the first field of your struct like so:

public unsafe struct Foo
{
    public int X, Y;
    public ref Foo Current => ref *(Foo*) Unsafe.AsPointer(ref X);
}

And on a second thought, doesn't this do exactly what you want?

public static class Extensions
{
    public static ref T Current<T>(this ref T value) where T : struct => ref value;
}

[ufcpp]

namespace Hypothetical
{
    // If this were allowed,
    struct Foo
    {
        int value;
        public ref int X() => ref value;
    }

    // this couldn't be allowd.
    class Bar
    {
        public ref int M()
        {
            Foo x = new Foo();
            return ref x.X();
        }
    }
}

namespace Actual
{
    // C# 7.2 allows this
    class Bar
    {
        public ref int M()
        {
            Foo x = new Foo();
            return ref x.X();
        }
    }

    // because of this usecase.
    struct Foo
    {
        int[] array;
        public ref int X() => ref array[0];
    }
}

[Austin-bryan]

If you want this behavior just use class. This doesn't seem like the kind of thing that they'll change and likely has to do with the nature of struct

[Jeremy-Price]

@ufccp, that's a great point, it would restrict cases like that which we probably wouldn't want to do.

However, given that the use case is very helpful for writing efficient struct-based enumerators, and because you can write something like
public ref Foo Current => ref MemoryMarshal.GetReference(MemoryMarshal.CreateSpan(ref this, 1));
it seems like finding a way to support this kind of behavior more legitimately could be beneficial.

Here are two alternatives:

1. Allow returning ref this on methods marked as unsafe. This is basically what the marshal example does, but it would allow the more reasonable syntax (And is there a performance difference between returning ref this and the marshal one? I don't have any intuition for how expensive something like that would be.)

2. Apply an attribute to the return value which restricts the usages of a ref return. So with the attribute the semantics are what I proposed above. (Side note, it could also be possible to widen the usages by saying that the ref must point to something on the heap, that might be useful to someone too.)

[yaakov-h]

(2) would effectively bifurcate the entire ref safety semantics.

[Thaina]

@OyasumiLad This feature is needed when I want to attach interface to the same struct

[svick]

There is a proposal that will allow you to do this. As far as I can tell, the championed issue for that is #1147.

The issue raised by @ufcpp is addressed by requiring a special attribute an any struct method that returns this by ref and treating such methods differently.