special forms of struct and union which allow setting properties via comptime values

[andrewrk]

Add this to std.builtin:

pub const UnionProperties = struct {
    layout: ContainerLayout = .Auto,
    tag: union(enum) {
        none,
        auto,
        int: type,
        type: type,
    } = .none,
};
pub const StructProperties = struct {
    layout: ContainerLayout = .Auto,
};

New builtins and syntax

@struct(comptime props: StructProperties)
@union(comptime props: UnionProperties)

Use these in place of struct and union keywords respectively.

Existing struct and union syntax is unchanged. This is not a breaking proposal.

Example usage

const S = @struct(.{ .layout = .Extern }) {
   field1: i32,
   field2: f64,

   pub fn foo() void {}
};

const data_props: std.builtin.UnionProperties = if (safety_on) .{
   .layout = .Auto,
   .tag = .auto,
} else .{
   .layout = .Extern,
   .tag = .none,
};
const Data = @union(data_props) {
  one: i32,
  two: i32,
  pub fn decl() void {}
};

Motivation and real use case

The use case is having both safety in a safe build, and well-defined memory layout in release mode, for fast serialization/deserialization. We have exactly this use case in self-hosted compiler, for the Zir.Inst.Data union. I would imagine pretty much every video game will have this same use case.

It is also planned to experiment with adding safety to structs as well, so the same use case applies there as well.

Considerations with other open proposals

• Proposal: Change extern modifier for structs to mean "guaranteed layout", not "for use with C". #6700 now becomes a proposal to break ContainerLayout into more pieces: ordering, default alignment, allow non-C-ABI types. You can see how StructProperties and UnionProperties can be updated to support this, and the syntax proposed in this issue remains the same.
• Replace extern with extern(...) and layout(...) #4245 gets closed in favor of this one
• Proposal: Move container and function attributes (packed, inline, ..) to anonymous struct literal instead of using keywords #4285 gets closed in favor of this one. There are some ideas in there related to functions that would would need to get re-proposed taking this issue into account, if the people involved in that proposal wanted to pursue further changes.

[ghost]

So now the grammar of the language needs special cases for these builtins. Hmm.

[SpexGuy]

Builtins are already a special case in the parser. The spec grammar will need to have some modifications made, but that would have been the case for any solution to this problem.

[LemonBoy]

From the syntax PoV I prefer what's proposed in #4245 where the optional UnionProperties/StructProperties go between struct/union and the opening brace. My reasoning is that:

1. I don't like builtins
2. @struct and @union become a second way of defining a container type
3. There's a precedent in extern "foo"

The only possible downside I see is that a user may specify a conflicting set of parameters (eg. extern struct (.{.layout = .Packed})), but that's easily caught by the compiler so... not a big deal?

Revised example usage

const S = struct (.{ .layout = .Extern }) {
   field1: i32,
   field2: f64,

   pub fn foo() void {}
};

[daurnimator]

Especially once we have #1717 I'm not sure why we should prefer this over enhancing @Type:

const S = @Type(.{
    .Struct = .{
        .layout = .Extern,
        .fields = &[_]StructField{
            .{ .name = "field1", .field_type = i32 },
            .{ .name = "field2", .field_type = f64 },
        },
        .decls = &[_]Declaration{
            .{ .name = "foo", .is_pub = true, .data = .{ .Fn = fn () void{} } },
        },
        .is_tuple = false,
    },
});

With some default values in std.builtin types and/or some helper functions, this could become more ergonomic.

[Inve1951]

This might run into #4630 or become a workaround for it.