proposal: inline structs

[nektro]

Since Zig's earliest days it has said that structs declared with an auto layout are subject to optimizations such as field reordering in order to enable the most efficient padding for example. As of #14336 this optimization is now in place in ways towards #168. However consider the following code:

const S = struct {
    a: struct {
        c: u8,
        d: u32,
    },
    b: struct {
        e: u8,
        f: u32,
    },
};

and compare that to:

const T = struct {
    a: u8,
    b: u32,
    c: u8,
    d: u32,
};

evaluating @sizeOf on each of these yields 16 and 12 respectively. This is due to the compiler not being able to void the assumption that s.a may be a valid immediate. or the user doing &s.a. this heuristic could be potentially performed during semantic analysis would be quite expensive and have many other ramifications. however, the writer may know ahead of time that they are only using the struct for semantic namespacing of the fields and are okay with telling the compiler ahead of time that the types won't be used as an immediate and thus the inner fields may be reodered as if the higher struct wasn't there. this is what inline struct provides.

assuming we edit S to use inline struct for the a and b fields,

• s.a is compile error
• &s.a is a compile error
• s.a.c is okay
• s.a.c = foo is okay
• @sizeOf(inline struct {..}) is compile error
• @alignOf(inline struct {..}) is compile error
• A or B would still show up in @typeInfo(S) with a layout of .Inline but cannot be reified through @Type
• @offsetOf(S, "a") is compile error
• @offsetOf(S, "a.c") working or not is up to the discretion of the implementer

acceptance and subsequent implementation of this proposal would make assert(@sizeOf(S) == @sizeOf(T)); pass.

[nektro]

"but what if you did this?"

const S = struct {
    a_c: u8,
    a_d: u32,
    b_e: u8,
    b_f: u32,
};

a and b being separate is important here since the inner fields are likely assigned together in a group, eg:

s.a = .{
  .c = 10,
  .d = 12,
};

I would want adding a field to A or B to be a compile error at all of these callsites and that is not possible with the underscore names, thus potentially leaving default values or even undefined bits in my value.

[nektro]

s.a = .{
  .c = 10,
  .d = 12,
};

"but didn't you say you can't create temporaries/immediates?"

yes and per-Result Location Semantics and observed in #12064 we see that the code above is semantically equivalent to the following which is totally valid per this proposal.

s.a.c = 10,
s.a.d = 12,

[nektro]

as for the driving use case, this is the first one i thought of https://git.sr.ht/~nektro/magnolia-desktop/tree/1ddabe69/item/src/ttf.zig#L83

[Cloudef]

"but what if you did this?"

const S = struct {
    a_c: u8,
    a_d: u32,
    b_e: u8,
    b_f: u32,
};

FYI, I think something like this could be done through comptime meta function that generates the namespaced struct for you.

[mlugg]

&s.a is a compile error

While this makes sense, it would make the proposal quite tricky to implement, since &s.a.c first evaluates &s, then gets &s.a, then &s.a.c. I suppose AstGen could be modified to encode sequences of field accesses in a single instruction, although we would then have to do this for RLS of initializations as well, which would be tricky and somewhat complicate the language spec.

In general, I don't like this proposal; I think it's solving a rather esoteric problem in exchange for what's actually a pretty fundamental change to the type system. This introduces a whole new class of type into Zig: types which, in a very real sense, aren't really types! They represent data, but you can't actually store an instance of them, and queries which are normally fine across the board like @sizeOf don't work.

If optimizing the memory footprint is of concern, then you're presumably storing a large array of these structs. Would a kind of "recursive MultiArrayList" data structure solve your use case better?

[nektro]

FYI, I think something like this could be done through comptime meta function that generates the namespaced struct for you.

I hadn't thought to try that before for this case, lemme give it a shot and report back.

This introduces a whole new class of type into Zig: types which, in a very real sense, aren't really types!

I think they share a lot of properties with comptime-only types but if it arrives that its too complicated for the benefit, that's fair.

[nektro]

before and after:

// Compile Log Output:
// @as(comptime_int, 256)
// @as(comptime_int, 8)

// Compile Log Output:
// @as(comptime_int, 248)
// @as(comptime_int, 8)

wrote the code to do this at comptime but I dont think i'll be continuing with this after it not being that much of a meaningful difference

[nektro]

posting the code in case anyone finds this later and really wants it

fn InlineStruct(comptime T: type) type {
    const info = @typeInfo(T).Struct;
    var new_fields: []const std.builtin.Type.StructField = &.{};
    for (info.fields) |old_field| {
        switch (@typeInfo(old_field.type)) {
            .Struct => {
                const other_info = @typeInfo(old_field.type).Struct;
                for (other_info.fields) |other_field| {
                    new_fields = new_fields ++ &[_]std.builtin.Type.StructField{.{
                        .name = std.fmt.comptimePrint("{s}_{s}", .{ old_field.name, other_field.name }),
                        .type = other_field.type,
                        .default_value = other_field.default_value,
                        .is_comptime = other_field.is_comptime,
                        .alignment = other_field.alignment,
                    }};
                }
            },
            else => {
                new_fields = new_fields ++ &[_]std.builtin.Type.StructField{old_field};
            },
        }
    }
    return @Type(@unionInit(std.builtin.Type, "Struct", .{
        .layout = .Auto,
        .backing_integer = null,
        .fields = new_fields,
        .decls = &.{},
        .is_tuple = false,
    }));
}

fn InlineStructMixin(comptime T: type, comptime inline_name: string, comptime I: type) type {
    return struct {
        pub inline fn inlineSet(this: *T, comptime field_name: std.meta.FieldEnum(I), value: std.meta.FieldType(I, field_name)) void {
            const F = std.meta.FieldType(I, field_name);
            switch (@typeInfo(F)) {
                .Struct => {
                    inline for (@typeInfo(F).Struct.fields) |field| {
                        @field(@field(this, inline_name), std.fmt.comptimePrint("{s}_{s}", .{ @tagName(field_name), field.name })) = @field(value, field.name);
                    }
                },
                else => {
                    @field(@field(this, inline_name), @tagName(field_name)) = value;
                },
            }
        }
    };
}