January 6, 2026, 7:05pm 1

I kinda think they aren’t! I think they’re a clean different thing, which is overloading the struct keyword, and maybe that part should change.

• A file is “just a struct”

• But a file can’t be a tuple

• But it can’t be an extern or packed either

• But tuples don’t take a modifier!

• We have @Struct coming up, do we use it to make a tuple?

• Nope! We use @Tuple. So why is its @typeInfo a .@"struct"? Of type Struct?

• Tuples are structurally typed, every .{ bool, bool } is the same type.

• Structs are very much not structurally typed, Foo{ .a: bool, .b: bool } is not at all a Bar{ .a: bool, .b: bool }.

• We can destructure a tuple, but not a struct, them we just construct.

• Tuples have a .len “field”, structs… I mean they can but, mostly, no.

OK, but we still need to define tuple types, somehow.

If not with struct, how? Keywords are expensive.

How about:

fn tupleator() .{ []const u8, []const u8 } {
return .{ "why", "not?" };
}

This is not ungrammatical, but currently gives the error:

error: type ‘type’ does not support array initialization syntax

Well.

What if it did?

mnemnion January 6, 2026, 7:16pm 2

That might be too galaxy-brained, “a tuple of types defines the type of a tuple of those types”. IDK maybe it’s perfect, but to illustrate my point:

const WhatAmI = .{ bool, bool };
// Currently:
// @TypeOf(WhatAmI) == struct { bool, bool };
//
// Becomes:
// @TypeOf(WhatAmI) == type;

Is this the good kind of punning? Do we ever need a tuple of types which isn’t a tuple type? Problem is we can make a tuple of anything now, so, losing that is probably bad. I think just handwaving it off and letting a type which is also a tuple do “tuple business” like .@"0" and .len is uh. That sounds, irregular.

But!

@Tuple(.{ bool, bool})

That creates a tuple already on master branch[1]. This is how we make @Vectors, why not tuples?

At that point why not just @Tuple(bool, bool) though. We have @TypeOf and @compileLog as variadics already, there’s precedent.

---

@Tuple(&.{bool, bool}), I believe. Surely we can drop the & though… ↩︎

hachanuy January 6, 2026, 7:30pm 3

I’m pretty sure the reason for not making @Tuple accepting variadic arguments is because you can’t construct variadic arguments dynamically, which throws out the value proposition of a function call instead of just writing struct {bool, bool}.

mnemnion January 6, 2026, 7:34pm 4

That is a credible reason not to ditch the inner .{}, good point.

Extremely cursed counterpoint:

@call(.auto, @Tuple, dynamic_tuple_types);

hachanuy January 6, 2026, 7:34pm 5

@call cannot invoke builtin functions

mnemnion January 6, 2026, 7:34pm 6

Oh ye of little faith

mnemnion January 6, 2026, 7:47pm 7

Oh, I completely forgot one of the most compelling arguments: tuples are not containers.

const Nope = struct {
bool,
bool,

pub fn uh_no(no: Nope) bool {
return no.@"0";
}
};

Gives:

error: tuple declarations cannot contain declarations

Not much of a struct!