Champion: fixed-sized buffers

[jcouv]

Introduce a pattern that would allow types to participate in fixed statements.

• Proposal added (https://github.com/dotnet/csharplang/blob/master/proposals/fixed-sized-buffers.md)
• Discussed in LDM
• Decision in LDM
• Finalized (done, rejected, inactive)
• Spec'ed

LDM history:

• briefly discussed in LDM on 2/7/2018 with some interest, identifying champion.
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-04-03.md#fixed-size-buffers
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-04-10.md
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-05-01.md#fixed-size-buffers
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-05-03.md#inline-arrays
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-05-17.md#inline-arrays

Tagging @VSadov @jaredpar

[glenn-slayden]

public fixed DXGI_RGB GammaCurve[1025];

// ...
DXGI_RGB my_rgb;

How is this different from...

[StructLayout(LayoutKind.Explicit, Size = 1025)]
public struct DXGI_RGB { }

// ...
DXGI_RGB my_rgb;

[tannergooding]

The latter is a struct which is 1025 bytes in size.

The former is an inline array of 1025 elements, where each element is a DXGI_RGB struct instance.

[portal-chan]

Shouldn't this

public fixed DXGI_RGB GammaCurve[1025];

be

public fixed DXGI_RGB[1025] GammaCurve;

The array thingy [] in C# always goes after the type name, not the variable name like in C/C++ so it looks kinda wrong to have it the other way around here. Unless I'm misunderstanding some part of this syntax 🤷‍♀️

[IS4Code]

The array thingy [] in C# always goes after the type name, not the variable name like in C/C++ so it looks kinda wrong to have it the other way around here. Unless I'm misunderstanding some part of this syntax

No, fixed-size buffers use this syntax to distinguish them from standard fields. GammaCurve is a fixed-size buffer field, not a field having an array type. DXGI_RGB[1025] is not a valid type name.

However, since a special type is always generated for such a field, why not introduce a new special type syntax fixed T[size] that refers to this type?

public static fixed int[5] GetValues() => return default(fixed int[5]);

This is effectively producing a by-val array. Then the syntax fixed DXGI_RGB[1025] GammaCurve; would be reasonable and valid.

[tannergooding]

Yes. Fixed-size buffers are an existing language syntax (which this proposal is extending) and are different from normal arrays (which are heap allocated and tracked by the GC). The syntax difference ensures the two features (arrays and fixed sized buffers) can be differentiated and updated independently without worrying about possible ambiguities.

[tannergooding]

However, since a special type is always generated for such a field, why not introduce a new special type syntax fixed T[size] that refers to this type?

@IllidanS4, see ref returns and Span<T>. However, that requires a stackalloc to allow use within functions and has various limitations to ensure that you aren't accessing memory from a stack frame that no longer exists.

[IS4Code]

No, there is a difference between my idea and Span<T>. Span<T> is a reference to an arbitrary location in the memory, but fixed T[size] is a by-value array. Moving a value of this type would move the whole array. In essence, fixed T[2] is like (T, T), fixed T[3] is like (T, T, T) and so on.

[tannergooding]

That would be a completely separate/distinct feature and would need its own proposal.

[airbreather]

How insane would it be to "just" allow consumers to use the existing fixed stuff as Span<T>?

Picturing...

struct MyStruct
{
    public fixed ulong Values[4];
}

class Program
{
    MyStruct s = default(MyStruct);
    Span<ulong> values = s.Values;
    Console.WriteLine(values.Length); // 4
}

Seems like "all it would take" (heh) is an attribute that tells the compiler the size of the field, and then the offset to the start of the buffer from the start of the struct could be either derived from metadata if sequential / explicit layout or computed live if auto layout (maybe at JIT time? I don't know how this one would work, sorry)... combine a ref to the the struct instance itself, the offset to start of fixed-size buffer, and the length of that fixed-size buffer (from the attribute), and that's enough to make what I think is a perfectly safe Span<T>.

Is this insane?

[airbreather]

Hmm, to answer my own question, without runtime support, that (edit: "that" = just exposing an easy safe way for callers to get Span<T> over the existing fixed-size buffer stuff) doesn't feel like enough to support the "any element type" part of the proposal, since if the buffer contains reference types, the GC would need to see each element of the fixed-size buffer as a separate reference to track. So it seems like there would still be a need to do something like the transformation in the current proposal, at least for reference types.

Right?

[IS4Code]

No, because there is nothing unsafe in the layout of the actual compiler-generated struct. Each element is represented by a separate field with the correct type, and since the whole struct is a field of the containing type, the runtime has perfect knowledge of all the references which may be stored inside.

[airbreather]

No, because there is nothing unsafe in the layout of the actual compiler-generated struct. Each element is represented by a separate field with the correct type, and since the whole struct is a field of the containing type, the runtime has perfect knowledge of all the references which may be stored inside.

Sorry, my comment was a bit ambiguous. I was positing a problem with my own Span<T> idea w.r.t. reference types and identifying this as a reason that we would still need something like the current proposal's compiler-generated struct with separate fields.