I love the fact that some file Foo.zig can directly represent a struct Foo. Unfortunately the same is not true of enums (as far as I know), resulting in lines like @import("MyEnum.zig").MyEnum.
The best idiomatic solution I can come up with is pub const @"*" = enum { ... }; in MyEnum.zig and then const MyEnum = @import("MyEnum.zig").@"*"; in Foo.zig.
Is there any reason a file couldn’t be inferred as either an enum or a struct based on the presence of literals or fields respectively, as they are mutually exclusive? I assume this has been brought up before, but I couldn’t find anything.
EDIT: I forgot about unions. Ideally there would be uniform approach that could work for these too. Perhaps imports statements themselves could disambiguate between unions and structs, while also providing required data such as the enum to use for the union. The simplest solution I can think of would be either multiple unique import builtins or some way to configure the current import for either modules, unions, structs or enums.
If you expand from struct to enum and union you may as well just say an imported file can be any type. I think I prefer the simplicity of saying it’s always an implicit struct (without braces etc) than having to handle import syntax differently depending on the type.
I think it is easier because namespaces are just structs, i.e. structs are how namespaces are represented in Zig. Files are also naturally namespaces, so it follows that file contents can be represented easily as structs.
This is a question of whether to add or subtract rules to the language.
I think the zig file was originally designed as a namespace.
The reason why it also serves as a struct type is merely to reduce the rules. Since the struct itself serves as both a namespace and a struct type with fields, if a zig file is designed as a struct, to illustrate that it is only used as a namespace and cannot be used as a struct type, additional restrictions need to be added in the language to express that “zig files are special; as a struct, they cannot have fields.” But it seems there is no particular need to restrict this.
However, if zig files are used for more types of aggregation such as union, tagged union, enum, packed struct, etc., more rules need to be added to zig files. From the perspective of usage, at certain times they seem more consistent. I dare not assert that this cannot be done in the future, but it will definitely add more grammar and rules, and there is no rush for this.