Why this code doesn't work anymore in master/0.14?

chung-leong · November 10, 2024, 9:29pm

The following code works in 0.13.0:

    const imports = .{
        .{ .name = "zigar", .module = zigar },
    };
    const mod = b.createModule(.{
        .root_source_file = .{ .cwd_relative = cfg.module_path },
        .imports = &imports,
    });

To get my code to compile using the latest master I had to attach a type to imports:

    const imports = [_]std.Build.Module.Import{
        .{ .name = "zigar", .module = zigar },
    };
    const mod = b.createModule(.{
        .root_source_file = .{ .cwd_relative = cfg.module_path },
        .imports = &imports,
    });

Just wondering what got changed.

swenninger · November 10, 2024, 9:38pm

Anonymous struct types have recently been removed:

github.com/ziglang/zig

Remove anonymous struct types from the language

opened 10:59AM - 17 Aug 23 UTC

closed 01:43AM - 01 Nov 24 UTC

mlugg

proposal accepted

This proposal is extracted from #16512, with more details and justification. …# Background Zig currently has the concept of an "anonymous struct type". This is a type which comes from an anonymous struct literal (`.{ ... }`) with no known result type. These types are special: they allow coercions based on structural equivalence which normal structs do not allow. For instance: ```zig const anon = .{ .x = 123 }; const S = struct { x: u32 }; const s: S = anon; _ = s; ``` This works because `anon` has an anonymous struct type, and all of its field types (in this case `comptime x: comptime_int = 123`) are coercible to those of `S`, so `@TypeOf(anon)` coerces to `S` field-wise. Anonymous struct types also allow even stranger coercions, such as allowing these coercions through pointers by creating new constants (e.g. `*const @TypeOf(anon)` coerces to `*const S`). # Justification I'm not entirely sure why anonymous struct types exist. My guess is that they originated before RLS, as the method for anonymous initializers to initialize concrete types. In that world, the concept makes sense, but today - with RLS - untyped anonymous initializers are **virtually never used**. Retaining anonymous struct types significantly complicates the language: * It introduces a new kind of type which cannot be differentiated by metaprogramming * It introduces [flawed coercions](/ziglang/zig/issues/16862) * It hides potentially expensive copies which could be trivially avoided when coercing to equivalent types * It leads to less readable code To pick up on the last point in particular: the only case where anonymous struct types are really used today is when writing code such as the above example. This kind of code would really benefit from a type annotation: it's unclear what `anon` is meant to be! Beginners sometimes write this kind of code expecting Zig to use the information from the later lines in type inference (inferring that `anon` should have type `S`): but anonymous struct types actually mask the issue here, potentially making code "work" whilst being harder to read, slower, and potentially buggier. Lastly, time to quantify a statement I made a moment ago: > ...untyped anonymous initializers are **virtually never used**. I looked at the ZIR for a few random files of real Zig code, and noted the following things: * The total number of struct init instructions * The number of anonymous struct inits (`struct_init_anon` or `struct_init_anon_ref`) * The number of those anonymous struct inits which would remain if #16512 were implemented | Source | Total Struct Inits | Anonymous Struct Inits | Would Remain With Better RLS | |----------------------|--------------------|------------------------|---------------------------------| | `Sema.zig` | 1199 | 4 | 0 | | `std/array_list.zig` | 29 | 1 | 1 (but removing improves code!) | | `std/mem.zig` | 47 | 1 | 0 | | `std/Build.zig` | 38 | 0 | 0 | | Bun: `js_parser.zig` | 814 | 0 | 0 | | Bun: `js_ast.zig` | 278 | 0 | 0 | You can see from these numbers that untyped inits rarely happen, and when they do, the proposed RLS improvements would eliminate them. Note that if you try, you *can* find some files which do genuinely use a lot of anonymous inits right now - for instance `arch/x86_64/Lower.zig` in the compiler has 107 at the time of writing - but as far as I can tell from a quick glance every single one of those would be eliminated by #16512. That proposal can essentially be considered a prerequisite of this one. # Proposal Eliminate anonymous struct *types* from the language. Untyped struct initializations are still permitted - they are useful for metaprogramming (e.g. `std.Build.dependency`'s `args` parameter) - but they return a "standard" `struct` type, with no extra allowed coercions etc. There's not much else to say. This is a proposal to remove an unnecessary concept from Zig: simplifying the language, encouraging code readability, and making us less prone to issues such as #16862.

github.com/ziglang/zig

compiler: remove anonymous struct types, unify all tuples

ziglang:master ← mlugg:no-anon-structs

opened 10:30PM - 26 Oct 24 UTC

mlugg

+1069 -1314

This commit reworks how anonymous struct literals and tuples work. Previously…, an untyped anonymous struct literal (e.g. `const x = .{ .a = 123 }`) was given an "anonymous struct type", which is a special kind of struct which coerces using structural equivalence. This mechanism was a holdover from before we used RLS / result types as the primary mechanism of type inference. This commit changes the language so that the type assigned here is a "normal" struct type. It uses a form of equivalence based on the AST node and the type's structure, much like a reified (`@Type`) type. Additionally, tuples have been simplified. The distinction between "simple" and "complex" tuple types is eliminated. All tuples, even those explicitly declared using `struct { ... }` syntax, use structural equivalence, and do not undergo staged type resolution. Tuples are very restricted: they cannot have non-`auto` layouts, cannot have aligned fields, and cannot have default values with the exception of `comptime` fields. Tuples currently do not have optimized layout, but this can be changed in the future. This change simplifies the language, and fixes some problematic coercions through pointers which led to unintuitive behavior. Resolves: #16865

dimdin · November 10, 2024, 11:20pm

The following builds correctly:

    const proper_module = b.addModule("proper", .{
        .root_source_file = b.path("src/proper.zig"),
        .imports = &.{
            .{ .name = "recover", .module = recover_module },
        },
    });

chung-leong · November 11, 2024, 11:39am

Well, that’s confusing. Moving an initializer to a const shouldn’t cause code to fail imho.

dimdin · November 11, 2024, 11:55am

    const imports = .{
        .{ .name = "zigar", .module = zigar },
    };

In this code, zig compiler does not know the type of imports.

In the following code, zig compiler can derive the type:

const proper_module = b.addModule("proper", .{
        .root_source_file = b.path("src/proper.zig"),
        .imports = &.{
            .{ .name = "recover", .module = recover_module },
        },
    });

addModule accepts Module.CreateOptions, and its member imports is []const Import.

chung-leong · November 11, 2024, 12:52pm

Comptime int, float, and enum literal don’t work this way. Nor do the other comptime-types like null and undefined.