Auto implement ref Property with variable of the same name

[Thaina]

Sometimes we have a field as exact same name as the ref property that need to implemented from interface. I think it could be auto generated if it is a ref property

public interface ISomething
{
     ref SomeObjectA A { get; }
     ref SomeObjectB B { get; }
     ref SomeObjectC C { get; }
     ref SomeObjectD D { get; }
}

public class SomeObject : ISomething
{
     public SomeObjectA A;
     public SomeObjectB B;
     public SomeObjectC C;
     public SomeObjectD D;
}

Instead of manually add property it should be able to generate explicit implementation automatically just at the compile time mapped with the same name as the field. It would be very convenient

And actually, with the same pattern, I think we could have a ref property member of interface could be implement like this without any code at all. All the new field could be just generated only at compile time at the end of the class and just magically available

public interface ISomething
{
     ref SomeObjectA A { get; }
     ref SomeObjectB B { get; }
     ref SomeObjectC C { get; }
     ref SomeObjectD D { get; }
     int OtherField { get; set; }
}

public class SomeObject : ISomething
{
    int otherField;
    // none ref member must be implemented normally
    public int OtherField { get => otherField; set => otherField = value; }
}

//////////////

var obj = new SomeObject();
obj.OtherField = 4;
obj.A = new SomeObjectA(); // available by auto generated

[PathogenDavid]

This is something I think would be a good candidate for code generation since it automates a repeated pattern which may or may not be domain-specific. You might consider mentioning it in #341.

---

Outside of the code generation pipe dream, I'd actually like to see support for auto-implemented ref properties instead. (Is there really not a proposal for this yet? I thought there was, but I can't find it.)

That way, SomeObject becomes:

public class SomeObject : ISomething
{
    public ref SomeObjectA A { get; }
    public ref SomeObjectB B { get; }
    public ref SomeObjectC C { get; }
    public ref SomeObjectD D { get; }
}

which would be equivalent to:

public class SomeObject : ISomething
{
    private SomeObject _a;
    private SomeObject _b;
    private SomeObject _c;
    private SomeObject _d;
    public ref SomeObjectA A => ref _a;
    public ref SomeObjectB B => ref _b;
    public ref SomeObjectC C => ref _c;
    public ref SomeObjectD D => ref _d;
}

[CyrusNajmabadi]

What is the point of using properties in your example? As the properties are writable (through the red) why not just expose the field directly? I don't see the purpose of the prop.

[BreyerW]

There was mine but much shorter proposal which got buried in history of csharplang #606

Edit ah someone deleted reply where he asked if there wasnt similar proposal and my post is mostly for him

[PathogenDavid]

@CyrusNajmabadi
ref properties are the closest you can get to having fields defined on an interface.

Normal get/set properties aren't enough when you want to be able to modify fields of a struct accessed via a property, for example:

using System.Numerics;

public interface IEntity
{
    Vector3 Position { get; set; }
    ref Vector3 PositionRef { get; }
}

public class Test
{
    public void Animate(IEntity entity)
        => entity.Position.X += 10f; // CS1612, can't modify `IEntity.Position`
    
    public void AnimateRef(IEntity entity)
        => entity.PositionRef.X += 10f;
}

@BreyerW
I asked in the middle of my comment, thanks for the link! I think yours came up in my search but I accidentally discarded it as unrelated.

[CyrusNajmabadi]

That seems bad. Your struct had now been boxed. I think of ref for lean and mean code that would be avoiding that. This seems to defeat the purpose

[Thaina]

@CyrusNajmabadi IEntity can be class. And we could define function as generic and it will not be boxed

[PathogenDavid]

How is the struct being boxed? The only thing that could get boxed here is the IEntity instance, but it isn't necessarily a struct in my example.

By "fields of a struct accessed via a property", I am referring to the X field of the entity.Position.

[CyrusNajmabadi]

I do understand that :-). It's just not that optimizing for the ergonomics around case is something I think it's particularly important.