New Modifier: 'instance' for the ref keyword

[TactiTac0z]

We add a new modifier which can be placed before 'ref' similar to 'scoped'.

an 'instance ref' variable, field (etc) is a ref but is constrained to only point to heap memory (aka only point to memory inside a class instance, array element, or static field.)

class TestClass
{
  instance ref int m_x;
  public TestClass(instance ref int x) // both method and constructor parameters may have 'instance' ref parameters
  {
    m_x = ref x; // an 'instance' ref (in this case a parameter) can be directly assinged to an 'instance' ref field.
  }
  void Method3(instance ref int x)
  {
     instance ref int x2 = ref x; // Local variables are allowed to be 'instance' ref
     m_x = ref x;
  }


  void Method1(instance ref TestStruct instanceRefY) 
  {
     int x = 0;
     Method2(ref x); // CSXXXX: local variable 'x' cannot be used as an argument for an 'instance ref' parameter
     Method2(ref s_x); // OK, we are giving a managed pointer to a static field
     Method2(ref m_x); // OK, we are giving a managed pointer to a class instance member
    
     var y = default(TestStruct);
     Method2(ref y.x); // Ok, the 'instance' managed pointer from the struct is passed directly to the method
     Method2(ref y.y); // CSXXXX: by-value struct member 'y' within local variable 'y' cannot be used an argument for an 'instance ref' parameter
     Method2(ref instanceRefY.y); // OK, the parameter is a struct but it's passed as an 'instance' ref thus by-value fields within the struct can be taken a managed 'instance' pointer from.

     var z = default(TestRefStruct);
     Method2(ref z.x); // CSXXXX: non-'instance' ref field 'x', cannot be used as an argument for an 'instance ref' parameter

     ref int a = ...;
     Method2(ref a); // CSXXXX: non-'instance' ref local variable 'a' cannot be used as an argument for an 'instance' ref parameter

     instance ref b = ...;
     Method2(ref b); // OK, similar to assigning a ref instance parameter to a instance ref field, this is allowed
  }
  void Method2(instance ref int x)
  {
    // do something
  }
  
}

struct TestStruct
{
  public instance ref int x; // like classes, struct can also have instance ref fields. 
  public int y;
}

ref struct TestRefStruct
{
  public ref int x;
}

How does that help us?
This allows us to have ref fields for classes and structs.

This may be pretty useful for asynchronous methods, you can imagine how asynchronous methods can use ref instance values just fine, since we don't have lifetime issues.
using ref within asynchronous methods is not allowed at all right now because the context of the method of course needs to be saved on the heap which would immediately break a by-ref variable containing a reference to the stack.

Imply 'instance'?

class TestClass
{
  // 'instance ref' could also be implied on non ref struct types like so:
  /*instance*/ ref int x;
 // that is debatable though, since that could potentially be confusing
}

Add 'instance' modifier to struct method declarations as well such that fields of that type can be passed by instance ref within that method?

struct TestStruct
{
  int x;
  instance void TestMethod() // The hidden 'this' argument is 'instance ref TestStruct' instead of only ref TestStruct in this method
  {
    instance ref int v = ref x; // so semilar to the above, the 'this' parameter is in it self ref instance so this is allowed.
  }

  // Like the 'readonly' struct method modifier and the 'readonly' ref modifier, 'instance' can be assigned to both the method and the ref return variable
  instance instance ref int TestMethod2()
    => ref x;
}

Callers of this new TestMethod method would then need a reference of 'instance' ref TestStruct to call the method.

The example of the double 'instance' modifier above brings up another question.
Should the 'instance' modifier be after 'ref' semilar to 'readonly'?
This fixes an ambiguity issue of instance ref Method() {}
It would be similar to 'readonly' but not similar to 'scoped', but for ambiguity reasons it may have to be at the end not in front.

I'm open to use a different keyword instead of 'instance' like maybe 'managed', 'heap', etc?

This feature does need runtime changes, but I think most issues regarding holding the referenced object alive for the gc have been solved with the addition of ref fields for ref structs already.

[RikkiGibson]

Ref fields on the heap don't work, even if those refs are constrained to refer to heap memory, because of the "interior pointers" problem.

I don't recall the exact reasoning, but I think it's something like: having more than one address refer to the same object on the heap, such as an ordinary value of a reference type versus a ref to one of its instance fields, significantly increases the cost of GC tracking, to the point that it's a non-starter.

[TactiTac0z]

I would have thought that the interior pointers would also be there for refs on the stack as well.

Like

class Class1 
{
  public Class2 x;
}
class Class2 
{
  public int x;
}

ref int M(Class2 klass)
{
  // In this example the interior pointer might not be a problem (depending on how this method is consumed at least)
  // since if the return value of this method is only used on the stack space of the call site then the klass reference is gonna stay in scope that long as well
  return ref klass.x;
}

ref int M2(Class1 klass)
{
  // But it seems to me it becomes a lot more complex here.
  // since the 'x' field that is a referece to the Class2 type the int field is a member of could be set to null 
  // so we can't rely on the class reference it self to keep the object alive
  return ref klass.x.x;
}

perhaps the reasoning is more like "Doing the interior pointers check is expensive, but is worth the cost for stack frames only. But too expensive to allow heap objects which could be many megabytes potentually to do."?