Provide a mechanism for declaring c-style anonymous unions and structs.

[tannergooding]

Rationale

When writing interop code (and even occasionally in normal managed code), it is often necessary to declare union types and inline anonymous structs.

C# currently allows users to declare union types by decorating a struct with the [StructLayout(LayoutKind.Explicit)] attribute and then decorating each field with the [FieldOffset(int)] attribute.

However, the unions are a special type of explicit-field layout in that all fields exist at the same address.

These unions may additionally be part of a larger struct and may be 'anonymous'.

Proposal

C# should support a new union keyword which explicitly lays all fields out to the same address (FieldOffset: 0).

C# should additionally support a new anonymous keyword which indicates the inline type is explicitly unnamed.

Examples

Standalone union

public union struct IEEE_754_DOUBLE
{
    public double Value;
    public long RawBits;
}

Standalone union with anonymous struct

public union struct LARGE_INTEGER
{
    public anonymous struct
    {
        public uint LowPart;
        public int HighPart;
    }

    public long QuadPart;
}

Struct with anonymous union

public struct D3D12_RENDER_TARGET_VIEW_DESC
{
    public DXGI_FORMAT Format;
    public D3D12_RTV_DIMENSION ViewDimension;

    public anonymous union
    {
        public D3D12_BUFFER_RTV Buffer;
        public D3D12_TEX1D_RTV Texture1D;
        public D3D12_TEX1D_ARRAY_RTV Texture1DArray;
        public D3D12_TEX2D_RTV Texture2D;
        public D3D12_TEX2D_ARRAY_RTV Texture2DArray;
        public D3D12_TEX2DMS_RTV Texture2DMS;
        public D3D12_TEX2DMS_ARRAY_RTV Texture2DMSArray;
        public D3D12_TEX3D_RTV Texture3D;
    }
}

Other Thoughts

Like in C/C++, anonymous structs/unions should be accessible in the parent type (i.e. LARGE_INTEGER.LowPart rather than LARGE_INTEGER.<anonymous_struct_name>.LowPart)).

The developers who will use this likely fall into the same category as those that would use blittable and bit field layouts.

[tannergooding]

In the above examples...

IEEE_754_DOUBLE would be emitted as:

[StructLayout(LayoutKind.Explicit)]
public struct LARGE_INTEGER
{
    [FieldOffset(0)]
    public double Value;

    [FieldOffset(0)]
    public long RawBits;

}

LARGE_INTEGER would be emitted as:

[StructLayout(LayoutKind.Explicit)]
public struct LARGE_INTEGER
{
    [FieldOffset(0)]
    public <SpecialCompilerTypeName> <SpecialCompilerFieldName>;

    [FieldOffset(0)]
    public long QuadPart;

    [StructLayout(LayoutKind.Sequental)]
    public struct <SpecialCompilerTypeName>
    {
        public uint LowPart;
        public int HighPart;
    }
}

D3D12_RENDER_TARGET_VIEW_DESC would be emitted as:

[StructLayout(LayoutKind.Sequental)]
public struct LARGE_INTEGER
{
    public DXGI_FORMAT Format;
    public D3D12_RTV_DIMENSION ViewDimension;
    public <SpecialCompilerTypeName> <SpecialCompilerFieldName>;

    [StructLayout(LayoutKind.Explicit)]
    public struct <SpecialCompilerTypeName>
    {
        [FieldOffset(0)]
        public D3D12_BUFFER_RTV Buffer;

        [FieldOffset(0)]
        public D3D12_TEX1D_RTV Texture1D;

        [FieldOffset(0)]
        public D3D12_TEX1D_ARRAY_RTV Texture1DArray;

        [FieldOffset(0)]
        public D3D12_TEX2D_RTV Texture2D;

        [FieldOffset(0)]
        public D3D12_TEX2D_ARRAY_RTV Texture2DArray;

        [FieldOffset(0)]
        public D3D12_TEX2DMS_RTV Texture2DMS;

        [FieldOffset(0)]
        public D3D12_TEX2DMS_ARRAY_RTV Texture2DMSArray;

        [FieldOffset(0)]
        public D3D12_TEX3D_RTV Texture3D;
    }
}

[tmat]

I'm not sure these use cases warrant new keywords. Seems like there are already enough features to declare these interop types. Yes, it's not super concise but it's interop - very few types in most apps would use this.

[tannergooding]

I think C# is taking a direction where these type of structures may become more commonplace (especially as we provide more safe ways to deal with memory, such as Span, ref readonly, etc).

These type of structures are used in interop for certain, but they are also very applicable to high-performance and low-memory code, such as code which framework authors may use.

[tannergooding]

At the very least, I think union is worthwhile. I'm not sold on how to best declare inline anonymous unions/struct (C just declares them as a struct without a name).

[sirgru]

I'm not sure that inclusion of a new keyword is realistic, especially for special-case code. Maybe there could be a special attributes [Union] and [Anonymous] that would do the same thing but help with verbostiy?

[tannergooding]

I think this is one of the cases where new 'keywords' is very realistic. The keywords would be considered contextual and would have similar semantics to 'partial' (they can only appear directly before the struct keyword). So there would be zero chance that it conflicts with existing code and users would not need to escape it to work with new code (this is similar to the 'blittable struct' proposal).

[sethrudesill]

I like the new keywords.

[fanoI]

I want to add an important scenario in which C# is used that is partly similar with interop: Cosmos that is writing an operating system using C# itself! Anything that permits us to talk better with the hardware without the need to use unsafe code or X# (assembler) is welcome.

In the "baroque" X86 architecture surely there will be cases in which we will need something similar to C unions...
Blittable and bit field layouts are other things that will be surely needed.

[HaloFour]

The problem that I have with this is the same problem I have with exposing any autogenerated type, that name becomes a part of the contract. Even if that doesn't matter in interop scenarios it certainly matters in non-interop scenarios and I don't see a way to forcibly prevent the latter short of forcing these types to be nested and private. The method through which that name is generated would end up having to be very strictly defined and embedded in the C# specification to allow for consuming code to survive a recompilation of a dependency as well for other compilers to predictably use the type.

[HaloFour]

That and this interop "concern" has been around since C# 1.0 and it doesn't seem to have posed a real problem for people writing said interop code. I've translated a ton of Win32 API myself and don't believe I've ever found the process that onerous. It's always nice to have to type less, but at this point is there that much more interop code that needs to be written? Even for anything new it's generally once-and-done and you can find the types/signatures somewhere to copy&paste or reference in some glue assembly.

[AustinBryan]

These keywords can be contextual so there'll be no way of it causing issues. From what I understand, it's already possible to get this effect, just in a very verbose manner. And, seeing as C# is very big on syntactic sugar and making us need to type less, I think this is a very realistic idea.

You might think that there's no chance because people have wanted this for ages and still haven't got it, but I think now there is a good chance. The latest C# updates have included new ways to use memory management in a much more safer way. I believe it was Made himself that said he wanted to give C# more low level features

[sgf]

i hope got this in C#

[Korporal]

It strikes me that this might possibly be achieved with an additional LayoutKind enum member like Union or Overlayed.

[StructLayout(LayoutKind.Union)]
public struct IEEE_754_DOUBLE
{
    public double Value;
    public long RawBits;
}

?

[tannergooding]

That's no different than the existing:

[StructLayout(LayoutKind.Explicit)]
public struct IEEE_754_DOUBLE
{
    [FieldOffset(0)]
    public double Value;

    [FieldOffset(0)]
    public long RawBits;
}

This is more about cases like:

public unsafe partial struct OVERLAPPED
{
    public nuint Internal;
    public nuint InternalHigh;
    public _Anonymous_e__Union Anonymous;
    public HANDLE hEvent;

    [UnscopedRef]
    public ref uint Offset => ref Anonymous.Anonymous.Offset;

    [UnscopedRef]
    public ref uint OffsetHigh => ref Anonymous.Anonymous.OffsetHigh;

    [UnscopedRef]
    public ref void* Pointer => ref Anonymous.Pointer;

    [StructLayout(LayoutKind.Explicit)]
    public unsafe partial struct _Anonymous_e__Union
    {
        [FieldOffset(0)]
        public _Anonymous_e__Struct Anonymous;

        [FieldOffset(0)]
        public void* Pointer;

        public partial struct _Anonymous_e__Struct
        {
            public uint Offset;
            public uint OffsetHigh;
        }
    }
}

Where it would be conceptually nicer to not have to declare and expose an internal implementation detail plus UnscopedRef properties to make access "simple".

It would also avoid the issue that the current approach doesn't work as nicely with readonly since the properties are considered "mutable".

[Korporal]

Regarding:

LARGE_INTEGER.<anonymous_struct_name>.LowPart this raises a difficulty:

public union struct LARGE_INTEGER
{
    public anonymous struct
    {
        public uint LowPart;
        public int HighPart;
    }

    public long QuadPart;
}

If changes were made to LARGE_INTEGER one would need to ensure that existing consumer code still works even if other anonymous structures were included that used the same member names existing anonymous structs. In other words how to guarantee that LARGE_INTEGER.LowPart never becomes ambiguous.

Also how could one even have multiple anonymous structs when they have no name?

[CyrusNajmabadi]

@Korporal your code block is empty:

[tannergooding]

Also how could one even have multiple anonymous structs when they have no name?

Anonymous structs don't actually have "no name", they have a synthesized "unspeakable" name. It's ultimately just compiler magic/syntax sugar that makes it simple to access the appropriate members.

This is true even in C/C++ and there are cases where declaring the fields inline in C# (as many interop users try to do) are strictly incompatible with the real native definition (because all anonymous structs are real structs and have a packing boundary between them and the prior field).

-- It's also notably unlikely that the C# team will end up taking this feature, let alone it getting prioritized enough to actually make it in

If there was a way to rewrite user code, a source generator could make this "nicer". The same could be said if there was a way to indicate that a ref T Property could be treated as readonly if used as in (that is, it causes no mutations to the struct directly, but a user could indirectly mutate via the ref; so only perform a hidden copy if they try to mutate).