[API Proposal]: stackalloc inside ref struct

[CodingMadness]

Background and motivation

You can do a lot of things with it when you can store arrays inside the restricts which are stack allocated and have no need to exist longer than they have to.

API Proposal

namespace System.Collections.Generic;

public ref struct CustomIterator<T> where T: unmanaged
{
      private Span<T> data = stackalloc T[<const size >]
}

API Usage

// use it inside the ref struct "CustomIterator()"
public bool MoveNext()
{
      for(int i = 0; i < data.Length; I++)
         data[I] = GetRnd_T();  //whatever here..
}

Alternative Designs

No response

Risks

Not AFAIK

[ovska]

Your example of a constant-sized stackalloc can already be achieved like this:

public ref struct CustomIterator<T> where T: unmanaged
{
    private Span<T> _data;

    public CustomIterator(Span<T> data)
    {
        _data = data;
    }
}

public static void Something()
{
    var iterator = new CustomIterator<byte>(stackalloc byte[128]);
}

[svick]

This belongs to dotnet/csharplang, where this is effectively a part of #1502.

[CodingMadness]

This is partially a solution but you dont always want to pass that stackalloc from the outside, cause you may need it for specific calculations and you know exactly the length at compile time inside the ref-struct. RIght now i have such an instance where i dont want outsiders to define what and how large the storage shall be and even then allow that thing outsiders to even utilize.

Its nice that you even have the chance to do that, but its really not an all case scenario solution.

I would think that, since we can have Span<byte> data = stackalloc byte[xy] and we already have ref-structs with ref fields and so, that it would not be far off to allow this type aswell be usable inside the ref struct itself.

[CodingMadness]

Your example of a constant-sized stackalloc can already be achieved like this:

public ref struct CustomIterator<T> where T: unmanaged
{
    private Span<T> _data;

    public CustomIterator(Span<T> data)
    {
        _data = data;
    }
}

public static void Something()
{
    var iterator = new CustomIterator<byte>(stackalloc byte[128]);
}

Another flaw with your design is that you would allow potentially evrything to be passed, which can be dangerous. So this is prevented with my api-choice aswell.

PS: I shall remove the where T: unmanaged constraint because i need a 3-tuple insidethat enumerator; So i need a fixed-size pool of that, which is sadly not possible with the usual "fixed T[10]" cause it only can contain primitive datatypes.

[IS4Code]

It would seem to me that a better solution would be to make this possible then:

public ref struct CustomIterator<T> where T: unmanaged
{
      private fixed T data[<const size >];
}

Plus to be able to treat data as Span<T> without unsafe (not sure if that is possible already).

[CodingMadness]

It would seem to me that a better solution would be to make this possible then:

public ref struct CustomIterator<T> where T: unmanaged
{
      private fixed T data[<const size >];
}

Plus to be able to treat data as Span<T> without unsafe (not sure if that is possible already).

yea fixed does all that, except like u cant use ValueTuples with it

[DL444]

+1 for the proposal. The problem of the injected-span workaround is ownership. If the ref struct is supposed to own the span, allowing the struct itself to stackalloc the span would guarantee ownership. With an injected span, ownership is not guaranteed, and the injector could mutate the span unexpectedly to the struct. With this workaround you have to rely on documentations to make the ownership intention clear and hoping that your consumers would follow the rules, and the lack of ISpanOwner<T> also doesn't help.

[colejohnson66]

The nature of the IL requires that stack allocations only be valid for the length of the method. Hence the workaround of passing it into the constructor.

[DL444]

Yeah, never considered the possibility of ref structs leaking outside of the current method by return and out parameters. Guess there isn't much that can be done then.

[CodingMadness]

But I do wonder, why is that the need if the compiler can guarantee that the entire ref-struct will be auto-deleted once the method it was defined in, exceeds?

So consider this:
`

	  public void OutsideMethod()
       {
                int maxNumbers2Iterate = 100;
                CustomIterator<int> myNumbersCounter = new(maxNumbers2Iterate); 

	           foreach(var x in myNumbersCounter )
	           {
	                  Console.Write(x); //whatever here...   
	           }   


      }//----------------->right here, the "myNumbersCounter" will be discarded and anything inside it as well.  Now I ask, why cant the compiler team make an allocation somehow bound, even maybe with a new keyword or so, to the entire ref-type because it would ensure automatically that it wont exceed the methods body and hence could be safe to implement, or where is my logical flaw?

`

[DL444]

As already said, ref structs can actually escape the current stack frame via return value or out parameter. For example, this compiles and works today:

bool TryGetStruct(out Struct structure)
{
    structure = new Struct(new byte[4]);
    return true;
}

void Demo()
{
    TryGetStruct(out Struct structure);
    Console.WriteLine(structure.Bytes.Length);
}

ref struct Struct(Span<byte> bytes)
{
    public Span<byte> Bytes { get; } = bytes;
}

If we allow Struct to stackalloc the Bytes internally, then structure.Bytes in Demo() would dereference invalid memory locations.

The compiler will check and forbid passing stackalloced buffer to the ctor in TryGetStruct(), so the problem is avoided.

bool TryGetStruct(out Struct structure)
{
    structure = new Struct(stackalloc byte[4]); // Error: CS8347, CS8353
    return true;
}

[CodingMadness]

I am 100% with you, this is a thing they really could enforce/ensure and all would be good, they really need to open up this entire ref struct thing because it has soooooo much potential....

[colejohnson66]

As an alternative, you can today do roughly what you’re asking for with InlineArray. If you are indeed stack allocating a constant amount, the following will work:

public ref struct MyStruct
{
    private Store _store;

    [InlineArray(42)]
    private struct Store
    {
        private T _element0;
    }
}

In this case, the stack allocated memory is part of the ref struct, so returning it further up the stack will copy it.

[CodingMadness]

the only issue with this is, it is only constant, you cant use computed values like you can already with stackalloc... :/

[CodingMadness]

like this:
Span<char> text2 = stackalloc char[Random.Shared.Next(2, 100)];

[dellamonica]

I was actually going to write this very proposal, except for the length which in my case would be dynamic. Right now it is a pain to have ref structs with several "local" inner spans. For unmanaged types my "default" is to have a static method that determines how many bytes are needed by the type and the constructor takes in a Span of that length to initialize the various inner spans casting to their unmanaged types. Not ergonomical at all!

The C# compiler could potentially move the stackalloc to the caller of the constructor, but this is tricky to do and it won't be done. Perhaps the only solution would be for the runtime to track lifetimes scoped to the ref-struct itself.

[CodingMadness]

Btw this problem, atleast on a library level is kinda solved by The next big .NE(X)T framework, called, .NEXT:

Buffers