[Proposal]: Explicit Field Layout Improvements

[timcassell]

Explicit Field Layout Improvements

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

Expand explicit field layouts to allow native word-size offsets and automatic offsets for unknown field size.

Motivation

Currently, because FieldOffsetAttribute only allows you to specify the offset in bytes, if you have more than 1 reference field, you have to choose between only supporting 32-bit runtime by offsetting reference fields by multiples of 4 bytes, always offset reference fields by multiples of 8 bytes, wasting space in 32-bit runtimes, or don't use explicit layout.

The C# 9.0 feature for native sized integers nint/nuint further creates this need for explicit layout improvements to be as efficient as possible.

Additionally, explicit layouts are currently impossible with generic fields where the generics can be structs of unknown size (unless there's only 1 and it's placed after all other fields).

Detailed design

For offsets by native word-size, a new FieldOffsetAttribute constructor will be needed: public FieldOffsetAttribute(int offsetWords, int offsetBytes) where the actual offset is determined by the runtime by calculating IntPtr.Size() * offsetWords + offsetBytes.

[StructLayout(LayoutKind.Explicit)]
public struct M
{
    [FieldOffset(0)] // offset 0
    public object obj;
    [FieldOffset(1, 0)] // offset by 1 word
    public nint num1;
    [FieldOffset(2, 0)] // offset by 2 words
    public byte num2;
    [FieldOffset(2, 2)] // offset by 2 words + 2 bytes - adds 1 byte padding before this
    public short num3;
    [FieldOffset(2, 4)] // offset by 2 words + 4 bytes
    public byte num4;
    // remaining 3 bytes are padded.
}

sizeof(M) should be 16 in 32-bit runtime and 24 in 64-bit runtime.

--

For auto layout fields, a new FieldOffsetAttribute constructor could be made that accepts a new enum containing only a single option: public FieldOffsetAttribute(OffsetType offsetType). The runtime would decide how to offset these fields based on the type's size.

[StructLayout(LayoutKind.Explicit)]
public struct M<T1, T2>
{
    [FieldOffset(0)] // offset 0
    public object obj;
    [FieldOffset(1, 0)] // offset by 1 word
    public short num1;
    [FieldOffset(1, 2)] // offset by 1 word + 2 bytes
    public byte num2;
    [FieldOffset(OffsetType.Auto)] // auto offset
    public T1 t1;
    [FieldOffset(OffsetType.Auto)] // auto offset
    public T2 t2;
}

sizeof(M<byte, nuint>) should be 12 in 32-bit runtime and 24 in 64-bit runtime.
sizeof(M<object, short>) should be 16 in 32-bit runtime and 24 in 64-bit runtime.
sizeof(M<nint, long>) should be 20 in 32-bit runtime and 32 in 64-bit runtime.

Drawbacks

None.

Alternatives

None.

Unresolved questions

Should we use FieldOffset(OffsetType.Auto) or a new attribute like FieldOffsetAuto?

Design meetings

[YairHalberstadt]

I'm not sure this matters to the language at all? Perhaps this should be an issue for dotnet/runtime

[timcassell]

I'm not sure this matters to the language at all? Perhaps this should be an issue for dotnet/runtime

Hm, you may be right. If so, can someone move this issue?

[HaloFour]

It would need support from both the runtime and the language. FieldOffset is a pseudo-attribute and isn't emitted as a custom attribute into the assembly. I doubt the runtime understands the custom attribute. The C# compiler interprets the attribute during compile-time and emits the appropriate IL metadata:

[StructLayout(LayoutKind.Explicit)]
public struct Foo {
    [FieldOffset(4)]
    public int x;
}

.class public explicit ansi sealed beforefieldinit Foo
    extends [System.Private.CoreLib]System.ValueType
{
    .field [4] public int32 x
}

[bernd5]

Why not adding a constant Size field to IntPtr/UIntPtr and allow the usage here? That would be much simpler and more flexible...
Or simply allow "sizeof(nint)" like "sizeof(int)"

[alexrp]

Why not adding a constant Size field to IntPtr/UIntPtr and allow the usage here? That would be much simpler and more flexible...
Or simply allow "sizeof(nint)" like "sizeof(int)"

Because these things are not compile-time constants.

[bernd5]

It is a compile-time constant. But I think we can't express it in IL.
So at the moment it would only work while loosing multi-platform-support...

[timcassell]

It's not compile-time constant. You can compile a library to target AnyCpu for anyone to consume, there's no way to pre-determine the runtime for that.

[jnm2]

ℹ We ask in the issue template that you start new proposals as discussions unless a team member has invited you to create an issue.