Delegate ref/out params, when "real" ref/out isn't legal

[TahirAhmadov]

For cases where actual ref cannot be allowed (async methods, passing in a property), we declare special structs - Ref<T> and Out<T>:

struct Ref<T>
{
  public Ref(Func<T> getter, Action<T> setter) { ... }
  public T Value { get => ....; set => ....; }
}
struct Out<T>
{
  public Out(Action<T> setter) { ... }
  public T Value { set => ....; }
}

Then, we can have this:

async Task Foo(delegate ref int x)
{
  await Task.Delay(x);
  --x;
}
int y = 5;
await Foo(async ref y);

// compiles to
async Task Foo(Ref<int> x)
{
  await Task.Delay(x.Value);
  --x.Value;
}
int y = 5;
await Foo(new Ref<int>(()=>y, v=>y=v));

// and this
void Bar(delegate out int x) { ... }
class Baz { public int Prop { get; set; } }
var baz = new Baz();
Bar(out baz.Prop);

// compiles to
void Bar(Out<int> x) { ... }
class Baz { public int Prop { get; set; } }
var baz = new Baz();
Bar(new Out<int>(v=>baz.Prop = v)));

The biggest motivation here is nullability analysis. With a custom Ref<T> type (which is what I'm doing now in these cases), I can't use the NRT attributes (at least, the ones that are available currently).

[sab39]

I feel like this - or something like it - could be useful outside of async as well, if it could be designed in a way that allowed passing properties as well as fields and locals as ref or out parameters. May not be trivial to get it to work, but it sure would be nice if something like this (clearly not an actual motivating use case, just a syntax example) could be made to work:

class Foo
{
  int? Num { get; set; }
  bool TrySet(string str) => int.TryParse(str, out Num);
}

[TahirAhmadov]

That would be cool, however we can't change existing ref parameters because it's an actual type. With properties, something like the VB solution can work: declare a hidden local and then get/set property as needed.

Alternatively, in my proposal, instead of async ref, it could be delegate ref, and it's conceptually un-tied from async and creates a new signature - without affecting existing code; and also allowing properties, etc.

[RikkiGibson]

I think if a struct that looked like Ref<T> were added to the platform, we would probably want it to be a ref struct wrapper around a ref field.

It feels like if you are going to go to the trouble of creating delegates, you might as well just create a reference type to hold the field you want to pass "by reference" and pass that in instead.

[TahirAhmadov]

I think if a struct that looked like Ref<T> were added to the platform, we would probably want it to be a ref struct wrapper around a ref field.

If that can be passed to an async method, sure, that would work. However, it would preclude @sab39 's idea above.

It feels like if you are going to go to the trouble of creating delegates, you might as well just create a reference type to hold the field you want to pass "by reference" and pass that in instead.

I'm not sure how that can work. What if the field is already a class field? How can it be in 2 places at the same time? What would that reference type be?