Allow a ref field to refer to a ref struct type

[Delsin-Yu]

This is revived from dotnet/roslyn#62243, which enables the following:

ref struct R1<T>
{
}

ref struct R2<T>
{
    public ref R1<T> F; // error CS9050: A ref field cannot refer to a ref struct.
}

The Roslyn team member closed the issue as a language design issue , and it was forgotten.

[RikkiGibson]

low-level-struct-improvements.md says:

Decision Delay allowing ref field to ref struct until .NET 8 where we have scenarios that will help drive the rules around these scenarios. This has not been implemented as of .NET 9

So, one way you could help us make progress on this is to let us know how you plan on using it.

Because C# does not have an explicit lifetimes syntax a la Rust and likely will never have one, there are major challenges to allowing ref fields of ref struct type. It changes the language from allowing only a bounded number of ref-indirections (e.g. ref Span<int> param), to allowing an indefinite number of them.

For the existing bounded design we have made things work by introducing a number of distinct "well known" safe-contexts which equal the number of ref-indirections that can be expressed. Once RFRS is possible, there will probably be either a need for safe-contexts at a certain depth of nesting to be equal (which heavily constrains use sites), or, for some amount of unsafety to be present.

[timcassell]

It seems to at least be a soft blocker for functional interfaces #8816.

[jaredpar]

There is no way to have a mutable ref to a ref struct without adding explicit lifetimes to the language. At the moment there are no plans for doing that. It would be a rather significant syntax update, even if we got it in through annotations in attributes, and it would need significant justification. That hasn't manifested.

I think it's likely that we will get ref readonly to ref struct in .NET 11 or soon after. That is mostly an exercise in proving it's safe, updating a few rules and removing a few errors in the compiler. From there experts can use unsafe to get mutable access to the value in the cases they are able to convince themselves the lifetimes are correct.

The Roslyn team member closed the issue as a language design issue, and it was forgotten.

It is in no way forgotten. The trade off for solving this is well understood, it's just not deemed worth it presently.

[RikkiGibson]

I think it's likely that we will get ref readonly to ref struct in .NET 11 or soon after.

Ahh, now I see how it works.

Yeah, if you require ref readonly, you can just say that the RFRS and its referent have the same safe-context. Since a readonly nested safe-context is "covariant", use sites where we infer that the referent has "wider" safe-context will convert to that "equal" safe-context without problems. So, ReadOnlySpan<Span<int>>, ROS<ROS<Span<T>>, etc., are possible without much compromise.

I don't think there's nearly as much case where people would want to pass around Span<Span<T>>, and write different Span<T>s to elements of the outer span anyway.

[jinsediaoying]

Here is my use case.
When I write custom IMessagePackFormatter for MessagePack, a very common pattern is:

public class MyObj;

public class MyObjFormatter : IMessagePackFormatter<MyObj?>
{
	public MyObj? Deserialize(ref MessagePackReader reader, MessagePackSerializerOptions options)
	{
		options.Security.DepthStep(ref reader);//those two lines are always togather

		//codes that do deserialization
		MyObj obj = new();

		reader.Depth--;//those two lines are always togather

		return obj;
	}

	public void Serialize(ref MessagePackWriter writer, MyObj? value, MessagePackSerializerOptions options)
	{
		throw new NotImplementedException();
	}
}

So I want to simplify it with using scope pattern.

public MyObj? Deserialize(ref MessagePackReader reader, MessagePackSerializerOptions options)
{
	using (new DepthScope(ref reader, options))
	{
		//codes that do deserialization
		MyObj obj = new();
		return obj;
	}
}

Note that MessagePackReader reader is a ref struct.
So the ideal form of that DepthScope would be:

public readonly ref struct DepthScope
{
	readonly ref MessagePackReader _reader;//not allowed

	public DepthScope(ref MessagePackReader reader, MessagePackSerializerOptions options)
	{
		_reader = ref reader;
		options.Security.DepthStep(ref reader);
	}

	public void Dispose()
	{
		_reader.Depth--;
	}
}

But this is not allowed.
I'm currently using unsafe code to do the job:

public readonly unsafe ref struct DepthScope
{
	readonly MessagePackReader* _reader;

	public DepthScope(ref MessagePackReader reader, MessagePackSerializerOptions options)
	{
		fixed (MessagePackReader* ptr = &reader)
		{
			_reader = ptr;
		}
		options.Security.DepthStep(ref reader);
	}

	public void Dispose()
	{
		_reader->Depth--;
	}
}

Basicly, It is the case where you want to write a using scope pattern that involves ref struct param.

[RikkiGibson]

I don't think this scenario would be solved by permitting ref readonly MessagePackReader _reader. You need to be able to mutate the _reader. i.e. unsafe code would still be needed here.

It seems like the DepthScope type ideally wouldn't need to hold a reference to MessagePackReader--or at least somehow exclude the ref fields of it. Rather it would just hold a reference to Depth. But Depth is a property, not a field. It's a conundrum.

[timcassell]

The example used a readonly ref, not a ref readonly.

[RikkiGibson]

I know. But we can't give them readonly ref per #9152 (reply in thread).