Proposal: ref property with both ref getter and setter

[BreyerW]

Currently, you cannot declare something like this:

public ref int intTest{
     ref get{ return ref testIntField; }
     ref set{ 
             testField=value;
             OnPropertyChanged(ref value);
     }
}

And for good reason: there is no way to easily disambiguate Object.testInt=8; //ref getter of setter? both are valid

However, recently there is work to enable ref readonly. This feature should allow to disambiguate ref getter and ref setter like this:

public ref int intTest{
     ref readonly get{ return ref testIntField; }
     ref set{ 
             testField=value;
             OnPropertyChanged(ref value);
     }
}

Then in my previous example situation become clear: Object.testInt=8; //nope, cannot write to getter so resolve to ref setter, if present, error otherwise.

Caveats:

1. This example wont work as-is: Object.testInt=8;. Normally setter would be converted to something like this: set_intTest(ref int value). This means passing standalone values like 8 wont work without workaround.

One possible is to generate temporary variable and pass that variable.

2. There will be no way to mutate this property indirectly. Something like this

ref var ourInt =ref Object.intTest;
ourInt=6; //Nope, cannot write since readonly ref

Object.intTest=6; //however this should be still possible

wont work.

Possible Workaround: forget about ref benefits and allow only non-ref setter or allow non-ref setter as alternative option to developer (so responsibility is moved to developer).

Maybe someone have another idea?

Things to consider

Allow in for setter?

Use case

I believe it will mainly have certain benefits to game developers. Consider Entity object that consist of Position, Rotation and Scale + all Matrixes:

class Entity{

   public Vector3 Position{

      ref readonly get{
            return ref position;
      }
      ref set{
            position=value;
            OnTransformChanged(ref value);
      }
   }
   //repeat above pattern for rotation, scale and matrixes
}

As you can see this would yield massive performance boost in certain scenarios (especially for matrixes, where its normal to have 16 fields) while preserving ability to reliably fire events when one of the properties change.