[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

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[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