Proposal: "ref" property accessor

[IS4Code]

The standard property accessors, get and set, do not cover all operations that can be performed on a variable, because the "obtain reference" operation is missing. This proposes a new ref accessor that returns a user-defined reference with the type of the property.

Auto-generated properties are a perfect example of its use, because they always have a concrete backing field, and perform no error checking:

public int Property{get; set; ref;}

ref int x = ref Property;

This would be translated to something like this (without the metadata):

int field;
public int get_Property() => field;
public void set_Property(int value) => field = value;
public ref int ref_Property() => ref field;

ref int x = ref ref_Property();

In cases where the underlying storage is permanent and permits any values, this combines the encapsulation and elegancy properties provide with the speed and semantics of fields.

This is also extending indexers with array-like semantics:

class Buffer
{
    const int size = 1024;
    int length; //increased with other methods
    byte[] data = new byte[size];

    public byte this[int index] {
        get{
            if(index >= length) throw new ArgumentOutOfRangeException(nameof(index));
            return data[index];
        }
        set{
            if(index >= length) throw new ArgumentOutOfRangeException(nameof(index));
            data[index] = value;
        }
        ref{
            if(index >= length) throw new ArgumentOutOfRangeException(nameof(index));
            return ref data[index];
        }
    }
}

This class (with an added Write method) works as an extendable buffer with a top limit (unlimited if List<byte[]> is used) which can be addressed exactly like an array thanks to the ref accessor – ref byte b = ref buffer[0];.

Notice the redundant code in the indexer? Because both get and set can be implemented using the ref accessor, they can be auto-generated:

public byte this[int index] {
    get; set;
    ref{
        if(index >= length) throw new ArgumentOutOfRangeException(nameof(index));
        return ref data[index];
    }
}

The accessors will be generated like this (pseudocode):

public byte this[int index] {
    get{
        return *(ref this[index]); //* meaning "dereference" because this[index] without "ref" is ambiguous
    }
    set{
        *(ref this[index]) = value;
    }
    ref{
        if(index >= length) throw new ArgumentOutOfRangeException(nameof(index));
        return ref data[index];
    }
}

If the data stored by the class is not permanent (like List<T> with resizable arrays), the result of the ref accessor cannot be guaranteed to be correct when the array is resized, but the accessor can be still used as private:

public byte this[int index] {
    get; set;
    private ref{
        if(index >= length) throw new ArgumentOutOfRangeException(nameof(index));
        return ref data[index];
    }
}

This way, the consumer cannot accidentally obtain a reference to an invalidated array, but code duplication is still prevented.

Optionally, ref readonly may be used instead of ref to make the reference read-only (e.g. passable to in parameters).

As far as I know, no changes are needed to the metadata format since custom accessors are already possible (.other in CIL). The Reflection API would need to be updated with GetRefMethod (also obtainable via GetAccessors).

Languages that only understand get and set accessors would still profit from the compiler-generated ref_PropertyName method (and would be able to implement it).

There is a fundamental difference between a ref property and a ref accessor. Ref accessors preserve the original (non-ref) type of the property, allowing easier reflection, interface implementation, and compatibility with languages that don't support ref returns.

[jnm2]

I apologize if I'm missing the obvious! Why not make it a ref or readonly ref property with the existing get and set?

[Sergio0694]

I really like this idea, and having the ability to quickly declare a ref accessor like this would really be useful.

@jnm2 Having a third, optional ref accessor would make it easier to add that feature to existing properties and make the code more compact, otherwise you'd have to declare a separate, ref property, with a different name, just to have it return that reference.

[IS4Code]

Exactly, you would have to add a new property if you didn't want to change the API of your code (and practically impossible with indexers), and ref properties also cannot be used to implement an interface with a standard property. Also there are no auto-generated ref properties.

[yaakov-h]

So the concern here is binary compatibility?

For implementing an interface you could use explicit implementation:

public interface IFoo
{
    object Bar { get; }    
}

public class Foo : IFoo {
    public ref object Bar => ref bar;
    object bar;
    
    object IFoo.Bar => Bar;
}

[IS4Code]

@yaakov-h Binary compatibility is not the only concern, but also the possibility of shorter and (in my opinion) cleaner code. To be honest, ref properties have a bit different feeling semantically to me than ref accessors. Ref properties (which also impair the possibility of reasonable reflection on them) feel like a C++ approach to the problem, instead of using the full potential of properties.

Also explicit implementation is possible, but a bit wordy for something as simple as a property. Using the proposal:

public class Foo : IFoo {
	public object Bar { get; set; ref; } //no more code needed
}

No need to create a backing field, no need for explicit implementation. Just good old property but buffed up.

Compare:

interface IIndexable<TIndex, TElement>
{
    TElement this[TIndex index] { get; set; }
}

interface IRefIndexable<TIndex, TElement> : IIndexable<TIndex, TElement>
{
    new ref TElement this[TIndex index] { get; }
}

class MyClass : IRefIndexable<int, object>
{
    object[] arr;

    public ref object this[int index] => ref arr[index];

    object IIndexable<int, object>.this[int index]
    {
        get => this[index];
        set => this[index] = value;
    }
}

with:

interface IIndexable<TIndex, TElement>
{
    TElement this[TIndex index] { get; set; }
}

interface IRefIndexable<TIndex, TElement> : IIndexable<TIndex, TElement>
{
    TElement this[TIndex index] { ref; }
}

class MyClass : IRefIndexable<int, object>
{
    object[] arr;
        
    public object this[int index]
    {
        get; set; ref => arr[index];
    }
}

So the reasons are: unification, binary compatibility, semantics, and shorter code.

[Sergio0694]

I'd also be nice to be able to do the same for ref readonly accessors, like:

public int Property{get; ref readonly; }

That would be translated into something like:

int field;
public int get_Property() => field;
public ref readonly int ref_Property() => ref field;

Also, this proposal would be handy with classes that expose ref/ref readonly properties that are also supposed to be serialized using Newtonsoft.Json, which doesn't support ref properties. Right now the only solution is to declare a private field just for the serialization, like this:

[JsonProperty(nameof(Property))]
private int SerializableProperty => somefield;

public ref Property => ref somefield;

But with this new proposal, it should be possible to do just this:

[JsonProperty(nameof(Property))]
public int Property
{
    private get => somefield; // For serialization only
    public ref => ref somefield;
}    

Which looks a bit cleaner 👍

[IS4Code]

@Sergio0694 Yeah, I was thinking about this possibility with the in/out keyword instead of ref, but I suppose ref readonly makes more sense since it's the same accessor.

At the moment, the development of C# kinda gets ahead of CLR, with by-ref reflection not implemented at all, and by-ref-like types still not supported as returns.

[copernicus365]

I am firmly in the camp of those extremely eager to see the ability to pass a property by ref (or by out, but at least by ref). If adding a whole new ref; specifier, as is suggested here, alongside get; and set; (e.g. public int Age { get; set; ref; }) is the only way that's going to happen*, I could live with it, though some of this looks strange (* at least part of this suggestion has the benefit of being backwards compatible). But there is the big downside that this way, you have to own the type in order to pass properties by ref. But I'm really unsure and unclear on the rest of this suggestion, like having a full ref { } body within the property? Please, we just need a way to pass properties by ref, I don't care if that has to be limited to only auto-generated properties.

[IS4Code]

It is not the only way, but the other one is creating a temporary variable which is then assigned to the property after the method call, like what VB.NET does. The problem with that is that storing the reference into a variable is complicated, because accessing the property must be consistent with the reference in all places.

You cannot obtain a reference to a property if you don't own the type, because you don't have access to the underlying storage.

[Shadowblitz16]

I could only see this useful if you could reference any visible property in the .net framework.

for example most properties in the framework would not be reference properties so this feature as it stand wouldn't be useful

//not a reference property
int MyInt1
{
 get;
 set;
}

//should be valid
ref int myint = ref MyInt1

[333fred]

I could only see this useful if you could reference any visible property in the .net framework.

for example most properties in the framework would not be reference properties so this feature as it stand wouldn't be useful

//not a reference property
int MyInt1
{
 get;
 set;
}

//should be valid
ref int myint = ref MyInt1

Properties are not necessarily backed by fields, this is not possible.

C# 7 added ref returns, which makes this perfectly valid C# code:

class C
{
    private int _i;
    public ref int P { get => ref _i; }
}

Other than adding a separate accessor for such a property, I don't believe this is adding anything beyond what the language already supports, so I'm going to close this out. Feel free to ping me if there's something I missed.

Nevermind, I see that the separate accessor is exactly the point of this proposal. Reopening.

[IS4Code]

@Shadowblitz16
Well, there is the possibility of adding the accessor automatically to all auto-implemented non-virtual properties. I doubt .NET Framework would be recompiled with this feature, but other regularly updated libraries will start to work with it once they switch to a new version of the language.

However, that might be dangerous, since it removes the abstraction properties have other storage, and once you add your own accessors, code that using ref would stop working.

I think adding public ref accessor requires a conscious change to properties and only to properties that (both now and in the future):

• Have a concrete storage location.
• Need no validation of the assigned value.
• Don't support the observable pattern.

Obviously not all proparties match these criteria, but a great deal of them do. Records are perfect candidates for this, but also advanced data structures, things that act as proxies over a storage location, and lazy properties. All the things that could be turned into a ref property, but the incompatibility with everything else stops you from doing that.

[bill-poole]

At the moment, if we need to have a property with a setter, but also need to be able to get a readonly reference to the underlying value, the only way to do that is by declaring two properties - which is messy, as shown below.

private Value _value;

public Value Value
{
  get => _value;
  set
  {
    _value = value;
    // Do something else, like notify of a property change
  }
}

public ref readonly ValueRef => ref _value;

So, we end up with a Value and a ValueRef property. It would be cleaner to just have a single Value property like below.

public Value Value
{
  ref readonly => ref _value;
  set
  {
    _value = value;
    // Do something else, like notify of a property change
  }
}

[HaloFour]

A ref property returns a reference to an underlying field. If the consumer mutates that reference there's no method call (thus no property setter) involved and there would be no way to include other logic, like notifying of a property change.

[bill-poole]

Yes that's true. But that's why in this case it is a "ref readonly" (as opposed to just "ref"). So, there is no possibility of the returned ref being mutated in this case; which is why the setter is there. That is, one would use the setter to set the value and the readonly ref operation to get a readonly ref to the underlying field.

[bill-poole]

Perhaps a better syntax below? i.e. we're still implementing a getter as per normal (i.e. implemented as a get_Value() operation). It's just that the getter returns a readonly ref to the value, rather than a copy of the value.

public Value Value
{
  get ref readonly => ref _value;
  set
  {
    _value = value;
    // Do something else, like notify of a property change
  }
}

[Flithor]

🤔

public class Args
{
    public Optional<T> source { get; set; }
}

Args args = LoadJson(json);
MyEFCoreEntity myObj = GetData();

// Before: 
if (args.source.IsDefined) myObj.Property = args.source.Value; // IsDefined means it's defined in json

// Currently legal:
static void TrySetValue<T>(this Optional<T> source, ref T target)
{
    if (source.IsDefined) target = source.Value;
}
args.source.TrySetValue(ref myObj.PropertyRef); // needs new property

// Currently illegal but I hope:
args.source.TrySetValue(ref myObj.Property); // now the ref property no setter then cannot be EFCore Entity

Well, maybe ref property shouldn't be used like this at all.