Enable grouping concept for ref structs

[richlander]

I have been using ref structs. They obviously come with constraints relative to classes or even regular structs. The one overly constraining constraint is the lack of any grouping concept. Pretty much all .NET apps deal in dictionaries, lists and arrays. It's incredibly useful to be able to deal with groups of things and some algorithms require it.

The only workable model I could devise was writing a type and capacity specific holder with an indexer, as demonstrated by TwoFooHolder:

public ref struct TwoFooHolder
{
    Foo _one;
    Foo _two;

    public TwoFooHolder(Foo one, Foo two)
    {
        _one = one;
        _two = two;
    }

    public Foo this[int i]
    {
        get
        {
            if (i == 0)
            {
                return _one;
            }
            else if (i == 1)
            {
                return _two;
            }
            throw new ArgumentOutOfRangeException();
        }
    }
}

This is what the consuming code looks like:

Span<int> data = new int[] { 0, 1, 2, 3, 4, 5, 6};
var foo = new Foo(data);
var holder = new TwoFooHolder(foo, new Foo(data[3..^2]));
for (int i = 0; i < 2;i++)
{
    var foo1 = holder[i];
    var foo2 = holder[(i+1) % 2];

    WriteLine($"Foo1 length: {foo1.Length}; Foo2 length: {foo2.Length}");
}

The code I wrote may appear a little contrived, but it is similar to the code I'm actually writing in an app.

The pattern above works, but it is far from convenient or pleasant. It's worse than .NET pre-generic days for collections that you wanted to be type-specific.

I'm not looking for access to the full breadth of .NET collections. What I really want is arrays for ref stucts, including params arrays. Arrays are attractive because they are simple, have great language support, enable random-access as a first class citizen and already have a stack-based implementation. In the limit, one can imagine enabling dictionaries, but that would require a bunch of new runtime concepts since a stack-based dictionary isn't something I can immediately imagine.

The following is a pattern that one can imagine supporting in a future C# version:

Span<Foo> fooGroup = stackalloc Foo[3] { foo1,foo2,foo3};

The only problem with it and also params arrays is it assumes perfect knowledge of the length of the data (w/o using a dynamic capability like ref emit). My particular use case does have that characteristic, but many will not.

[daveaglick]

I've actually been hitting this wall too on my first week out with ReadOnlySpan<char> as a replacement for strings in targeted low-level code. I know there are alternatives (like using ReadOnlyMemory<char> instead) but they all have drawbacks when the only precipitating factor for needing workarounds is the inability to group.

My use cases aren't particularly exotic and I don't consider myself a great low-level or high-performance developer. If I'm hitting this, I'm going to guess others are too (or will be), especially as ref struct objects are exposed more frequently to users (like all the Span plumbing going on).

[YairHalberstadt]

Related: #1148

This would allow you to make your containers generic, but fixed size.

Combining that with this proposal, you could store spans to ref structs in generic containers, whick should give you a lot more flexibility in the data structures you can define.

[richlander]

I didn't read that thread in detail, but I don't understand (A) how the stack-only invariant of ref structs is maintained, and (B) where the ref structs are stored. So, the constraint seems interesting mechanically, but I don't see how it brings us any closer to a solution on its own.

[YairHalberstadt]

@richlander

You would pass a span into the constructor of ref struct Store<T> where T : ref struct.

You can only store a span to a ref struct in a ref struct, or on the stack, so the stack only invariant would be maintained.

[richlander]

OK. That part makes sense. What would storage look like?

I tried to create a linked list with ref structs and failed after about 90s.

[YairHalberstadt]

public ref struct Store<T> where T : ref struct
{
    private Span<T> _backingSpan;
    public Store(Span<T> backingSpan)...
    this T [int i] get =>...; set =>...//set allowed here since it knows _backingSpan is a ref struct
}
...

Span<Foo> fooGroup = stackalloc Foo[3] { foo1,foo2,foo3};
var store = new Store<Foo>(fooGroup);
``|

[richlander]

OK. That makes sense. As you said initially, it is the two proposals together.

[richlander]

Related topic: #2584

[john-h-k]

This seems the ideal place to have some sort of where T : ref struct constraint, which, confusingly, would allow both ref structs and non ref structs, but would limit T as if it were a ref struct

[YairHalberstadt]

You can currently do this:

Span<Foo> fooGroup = stackalloc Foo[3] { foo1,foo2,foo3}; so long as Foo is unmanaged. The problem is Span<T> is managed.

So what this really depends on is being able to stackalloc managed objects. This would require runtime support. I opened an issue dotnet/runtime#38677 for this but for a different reason, but that was closed as an alternative proposal was preffered. I would recommend you open a new issue on dotnet/runtime and explain this scenario.

If that is done, allowing stackalloc of managed objects in C# will probably be a no brainer.