Error: Incompatible Types, but Why?

Kai_S · June 27, 2026, 9:14pm

I’m working on a falling tetromino game, and I got a compile error which is kind of confusing me:

minimal-example.zig:16:21: error: incompatible types: 'minimal-example.Piece' and 'minimal-example.main__struct_35611'
    const rotated = switch (pieceIndex) {
                    ^~~~~~
minimal-example.zig:17:14: note: type 'minimal-example.Piece' here
        0 => piece,
             ^~~~~
minimal-example.zig:18:15: note: type 'minimal-example.main__struct_35611' here
        1 => .{ .xs = threes - piece.ys, .ys = threes - piece.xs },
             ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is a sort of reduced example:

const std = @import("std");

pub fn main(init: std.process.Init) void {
    var buffer: [8]u8 = undefined;
    init.io.random(&buffer);
    var prng = std.Random.DefaultPrng.init(@bitCast(buffer));
    const random = prng.random();

    const pieceIndex = random.uintLessThan(usize, pieces.len);
    var piece = pieces[pieceIndex];

    const ones: V4u2 = @splat(1);
    const twos: V4u2 = @splat(2);
    const threes: V4u2 = @splat(3);

    // rotate counterclockwise
    const rotated = switch (pieceIndex) {
        0 => piece,
        1 => .{ .xs = threes - piece.ys, .ys = threes - piece.xs },
        2, 3 => .{
            .xs = @select(u2, piece.ys == ones, twos - piece.xs, piece.xs),
            .ys = @select(u2, piece.xs == ones, piece.ys, twos - piece.ys),
        },
        4, 5, 6 => .{ .xs = twos - piece.ys, .ys = piece.xs },
        else => unreachable,
    };
    piece = rotated;
}

const V4u2 = @Vector(4, u2);
const Piece = struct { xs: V4u2, ys: V4u2 };
const pieces: [7]Piece = .{ O, I, S, Z, L, J, T };

/// 1 1
/// 1 1
const O: Piece = .{ .xs = .{ 0, 1, 0, 1 }, .ys = .{ 0, 0, 1, 1 } };

/// 0 0 1 0  0 0 0 0
/// 0 0 1 0  0 0 0 0
/// 0 0 1 0  1 1 1 1
/// 0 0 1 0  0 0 0 0
/// initial rotation: 1
const I: Piece = .{ .xs = .{ 0, 1, 2, 3 }, .ys = .{ 1, 1, 1, 1 } };

/// 0 0 0  1 0 0
/// 0 1 1  1 1 0
/// 1 1 0  0 1 0
/// initial rotation: 0
const S: Piece = .{ .xs = .{ 0, 1, 1, 2 }, .ys = .{ 0, 0, 1, 1 } };

/// 0 0 0  0 0 1
/// 1 1 0  0 1 1
/// 0 1 1  0 1 0
/// initial rotation: 0
const Z: Piece = .{ .xs = .{ 1, 2, 0, 1 }, .ys = .{ 0, 0, 1, 1 } };

/// 0 1 0  0 0 0  1 1 0  0 0 1
/// 0 1 0  1 1 1  0 1 0  1 1 1
/// 0 1 1  1 0 0  0 1 0  0 0 0
/// initial rotation: 1
const L: Piece = .{ .xs = .{ 0, 0, 1, 2 }, .ys = .{ 0, 1, 1, 1 } };

/// 0 1 0  1 0 0  0 1 1  0 0 0
/// 0 1 0  1 1 1  0 1 0  1 1 1
/// 1 1 0  0 0 0  0 1 0  0 0 1
/// initial rotation: 3
const J: Piece = .{ .xs = .{ 2, 0, 1, 2 }, .ys = .{ 0, 1, 1, 1 } };

/// 0 0 0  0 1 0  0 1 0  0 1 0
/// 1 1 1  1 1 0  1 1 1  0 1 1
/// 0 1 0  0 1 0  0 0 0  0 1 0
/// initial rotation: 0
const T: Piece = .{ .xs = .{ 1, 0, 1, 2 }, .ys = .{ 0, 1, 1, 1 } };

Using Piece{…} instead of .{…} stops the compiler error, but I think I read somewhere that .{…} is preferred. I’m also not sure why the types are actually incompatible and it’s bugging me. This error even happens if you replace 0 => piece with 0 => .{ .xs = piece.xs, .ys = piece.ys }.

Any wisdom is appreciated.

edit: I forgot to mention, but this is 0.16.0.

Sze · June 27, 2026, 9:42pm

Use const rotated: Piece = switch ... that way all the switch prongs will have a result type and thus your .{} struct literals will be coerced to instances of Piece instead of being an anonymous struct type instance.

Kai_S · June 27, 2026, 9:46pm

Thanks! I’ll use this, but I still wonder why the anonymous struct literals were incompatible with piece.

Sze · June 27, 2026, 9:52pm

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.

Basically in the past Zig had structs that allow these coercions, but now you have to provide result type so that the struct literal can directly be coerced to the target struct type.

The previous semantics had too many corner cases which weren’t really useful and made the language more difficult to understand. (paraphrased)

0.14.0 Release Notes: Remove Anonymous Struct Types Unify Tuples