const Foo = @This();

value: i32,

pub fn init(val: i32) Foo {
return .{
.value = val,
};
}

const Foo = @import("foo.zig");

const foo = Foo.init(10);

const UnionEnum = union(enum) {
A: struct {a: i32, b:i32},
B: struct {c: bool},
}

// We can define something like this:

const UnionEnum = @union(enum);

A: struct {a: i32, b:i32},
B: struct {c: bool},

January 4, 2026, 10:42pm 1

I’m not sure if this has been discussed somewhere already, but I wanted to get feedback on this idea, whether it’s feasible and whether it aligns with the direction of the Zig language.

As we know Zig has file level structs that we can define as follows:

const Foo = @This();

value: i32,

pub fn init(val: i32) Foo {
return .{
.value = val,
};
}

and we can use it like this:

const Foo = @import("foo.zig");

const foo = Foo.init(10);

I wanted to ask if this could be possible for union(enum)

const UnionEnum = union(enum) {
A: struct {a: i32, b:i32},
B: struct {c: bool},
}

can be:

// We can define something like this:

const UnionEnum = @union(enum);

A: struct {a: i32, b:i32},
B: struct {c: bool},

and it would work as same principle.

This is just an idea that I came up please don’t take it too seriously just wanted to learn if its feasible or not.

Thank you in advance.

1 Like

I see one problem with this: Every file is always a struct. You dont need to do anything for that and you can’t do anything against that. If your example file is completely empty, you can still import and use it as a struct. It would be empty as well, of course. My point is that there is no place that says “this file is a struct" that you could change to say “this file is a union" or whatever.

1 Like

Yeah I guess so, if someone really wanted to implement this I guess the representation of file structs needs to change and I don’t think that’s feasible. I just get annoyed sometimes because of this: const UnionEnum = @import("union_enum.zig").UnionEnum; because I need to include with another access. It makes me feel like I am doing something wrong but I know there is nothing wrong.

It would be nice. As long as it’s just about making that a bit nicer though, I doubt it will ever happen. If there would be some real advantages to it, it would be more likely.

By the way, I found a thread about basically the same topic. It also hasn’t a lot of discussion though: .zig files as enum containers

lrworth January 5, 2026, 7:41am 5

It would also be awesome if a file could be a function or a const value (the latter would make zig a configuration file format). You could do something in the file extension, e.g. pi.const.zig could just contain some approximation of pi, generated by a block.

tsdtas January 5, 2026, 7:52am 6

How is that more ergonomic than something like @import(constants.zig).pi?

lrworth January 5, 2026, 8:06am 7

Because it would give a standard config file format. There are at least ziggy and Zon trying to do this, but they are restricted by not actually being zig.