Expose an attribute to allow sizing a fixed sized buffer based on type and element count.

[tannergooding]

Today, C# emulates fixed-sized buffers by emitting an explicitly sized struct with a single-field. This works decently enough for primitive types which have a constant size across varying platforms, but it does not work well for user-defined structs which may have different packing or different sizes across varying platforms/architectures.

This can be worked around by explicitly declaring a struct that contains x elements of type T, but this can quickly become overly verbose for fixed-sized buffers that contain many elements (e.g. 128 or even 1025).

I propose we expose an attribute that the VM will recognize and which it will use to dynamically size the type based on the information given.

This will allow a user to define something similar to:

public struct DXGI_RGB
{
    public float Red;
    public float Green;
    public float Blue;
}

public struct DXGI_GAMMA_CONTROL
{
    public DXGI_RGB Scale;
    public DXGI_RGB Offset;
    public _GammaCurve_e__FixedBuffer GammaCurve;    // DXGI_RGB[1025]

    [FixedSizedBuffer(typeof(DXGI_RGB), count: 1025)]
    public struct _GammaCurve_e__FixedBuffer
    {
        private DXGI_RGB e0;

        public ref DXGI_RGB this[int index] => ref AsSpan()[index];

        public Span<DXGI_RGB> AsSpan() => MemoryMarshal.CreateSpan(ref e0, 1025);
    }
}

This would also be beneficial for the fixed-sized-buffers proposal in C#, as it would avoid the metadata bloat problem that exists: https://github.com/dotnet/csharplang/blob/725763343ad44a9251b03814e6897d87fe553769/proposals/fixed-sized-buffers.md

[tannergooding]

CC. @jkotas, @jaredpar
Also CC. @davidwrighton, @VSadov who (IIRC) had previous thoughts in this area

Does this sound like something that would be feasible?

[tannergooding]

Such an attribute might end up looking like:

[AttributeUsage(AttributeTargets.Struct, AllowMultiple = false, Inherited = false)]
public sealed class FixedSizedBufferAttribute : Attribute
{
    public FixedSizedBufferAttribute(Type type, int count)
    {
        Type = type;
        Count = count;
    }

    public Type Type { get; }

    public int Count { get; }
}

[tannergooding]

This wouldn't quite work for pointer types, since you can't have typeof(T*), but maybe that could be resolved via an additional property: IsPointerType?

[jaredpar]

        public ref DXGI_RGB this[int index] => ref AsSpan()[index];

        public Span<DXGI_RGB> AsSpan() => MemoryMarshal.CreateSpan(ref e0, 1025);

For anyone reading ... please don't do this in practice. It violates our rules around lifetimes. Assuming @tannergooding just meant this as an example of how to implement this. Not as guidance for how to AV your application 😄

This seems sensible from the language side. But it does mean that we'd end up tying this feature to MemoryMarshal.CreateSpan which would limit its use down level.

[tannergooding]

Assuming @tannergooding just meant this as an example of how to implement this.

Right, Ideally this would all be handled by the compiler safely and behind the scenes (similar to how indexing a single element in a regular fixed sized buffer no longer requires pinning).

[jkotas]

This would not work for generics. Attribute arguments cannot use type parameters.

you can't have typeof(T*)

FWIW, this is artificial C# limitation. You can have typeof(T*) in IL just fine.

[jaredpar]

FWIW, this is artificial C# limitation. You can have typeof(T*) in IL just fine.

Is the behavior here to just return a Type object that represents a specific pointer type or general pointers? If it's just a limitation on our side maybe we should remove it when we remove the limitation of sizeof in unsafe code. Same theme of removing an artificial limitation.

[tannergooding]

This would not work for generics

That's a good point. I wonder if there is a good/clever way to workaround this limitation.

Not supporting generics would probably still cover most interesting interop scenarios, but would make writing certain types of managed performance optimizations a bit troublesome.

FWIW, this is artificial C# limitation. You can have typeof(T*) in IL just fine.

@jaredpar, is this something that I should log a language request for?

[jaredpar]

@tannergooding

is this something that I should log a language request for?

See https://github.com/dotnet/coreclr/issues/23408#issuecomment-475690498

[VSadov]

A while ago we had a proposal for "Inlined Indexable Data", aka "struct arrays".
A feature is similar to arrays in Go but a bit more fitting for C#.
There was even a working prototype, but not a lot of interest at the time.

I think you are really asking for struct arrays :-).

With that you could do the following:

public struct DXGI_RGB
{
    public float Red;
    public float Green;
    public float Blue;
}

public struct DXGI_GAMMA_CONTROL
{
    public DXGI_RGB Scale;
    public DXGI_RGB Offset;

    // IID variable. Can also be a class field, a parameter, a local, a threadstatic or whatever.
    // DXGI_RGB[1025] is just a sugared struct that statically knows its size and can be indexed.
    public DXGI_RGB[1025] data;     
}

DXGI_GAMMA_CONTROL ctrl = default;

Span<DXGI_RGB> span = ctrl.data[..]; //span escape is tied to ref-escape of ctrl, so this is safe.
ManagedHelper(span);

fixed (void* pData = &ctrl.data)
{
      NativeHelper(pData, ctrl.data.Length);
}

. . . 

I think struct arrays could be very useful, in particular for vector/matrix stuff like in graphics and ML.
If there is more interest now, I may resurrect that.

On the language side the feature is somewhat similar to tuples. There are N predefined structs and for N+ we nest. Perhaps a bit simpler than tuples, since there is only one TElement for the whole thing. There is much less type instantiation involved since nesting is tree-like not lists-like.

There could be some support needed on the runtime side -

• The prototype did not require any extras, but there were concerns with packing. Sequential packing of generic fields is not documented, but we would need to ensure that for underlying structs.
• As usual some extra magic like hoisting range checks could be nice too.
• Possibly a different mechanism to express the structs. I just used what worked already.

[tannergooding]

I think you are really asking for struct arrays :-)

Yes, struct (or "value") arrays are basically a natural extension of the fixed-sized buffer proposal. I remember you and I had talked about them a couple of times in the past.

I think one of the "key" differentiators is that fixed-sized buffers are largely used for interop code today and the primary goal of this extension is to remove what can be a pain point for interop code. While value arrays are likely more oriented towards managed code.

I do think this distinction becomes less important if the marshaller is able to deal with generic types (CoreCLR doesn't today, but Mono does) and if it can treat them as blittable (assuming the equivalent non-generic struct would be blittable), but until that happens, it is actually a fairly important distinction to have.

[jkoritzinsky]

There is an important note relating to fixed-buffers and interop: Up until a few months ago, very little effort was put into enabling good interop scenarios for fixed-buffers. As a result (for compat reasons), we don't actually correctly support non-blittable fixed buffers, and likely never will for compat reasons (see dotnet/coreclr#20194, dotnet/coreclr#20375, dotnet/coreclr#20558, dotnet/coreclr#20575).

[tannergooding]

@jkoritzinsky, wouldn't this new attribute allow it without breaking back-compat? That is, given that it requires explicit VM support and explicitly lists both the type and element count, it should always be marshallable correctly?

[tannergooding]

(unlike the existing attributes, which really relies on heuristics)

[jkoritzinsky]

If Roslyn were to continue marking char and bool fixed buffers in the old manner then we could easily distinguish between legacy non-blittable fixed buffers and the new fixed buffers, then we wouldn't have that problem.

The problem is that some people may have been incorrectly using Marshal.SizeOf<T> for types containing fixed char buffers. With the current behavior, it would be "correct" in the sense that it would be at least the value of sizeof(). However, if we were to allow char fixed buffers to be accurately calculated, then the value returned by Marshal.SizeOf<T> would (correctly) return a smaller value for ANSI fixed char buffers. But for people who currently use Marshal.SizeOf<T> instead of sizeof() for structures containing ANSI fixed char buffers, they might get a buffer overrun if they allocate space based off the Marshal.SizeOf<T>() route (since it doesn't require unsafe).

If Roslyn were to only mark non-primitive fixed buffers with the new attribute, we could more easily detect it and accurately account for it. However, it would be more difficult to correctly detect a char fixed buffer and fall back to the "legacy" behavior with the new system.