Proposal: expose tuple type declarations

[fengb]

We now have anonymous tuples, but they can only be created at runtime using the var type. While this satisfies "varargs" and coercion to arrays / vectors, we still cannot define a tuple type at comptime.

Potential syntax:

const Point = tuple{ i32, u32 }; // explicit, but adds a keyword
const Point = struct{ @"0": i32, @"1": u32 }; // matches the backend structure but feels pretty gross

Packed tuples should also be possible since it can represent in memory data structures pretty well, like manually managed stacks.

Accepted syntax

Per #4335 (comment):

const Point = struct{ i32, u32 };

[fengb]

Another usecase for declared tuples: emulating multiple returns.

[metaleap]

Do you foresee another .Tuple (vs .Struct) TypeInfo / TypeId for that (would intuitively advise against such) or have it more of a sugar building on the existing struct internals incl the existing "0", "1" etc auto-naming?

[andrewrk]

@typeInfo for tuples is the same as structs, but there will be an added flag is_tuple: bool

[metaleap]

Pondering it some more..

Hate to bikeshed, truly do usually, but would propose an alternative to "yet another keyword": extend the lang syntax such that struct {i32, bool, void} becomes valid and parses into an is_tuple struct (as we know it exists underlying already from .{10, "hi", false} literals) --- with the easy-to-intuit rule that either all fields must be named or all must be unnamed. If the parser can be made to do tuple{x,y,...} surely it can be made to do struct{x,y,...} =) whether the default-values part in a StructFieldNode (or however it's called internally) following a = should stay in here or go, I can't assess well right now but the same question would be for a tuple{} keyword.

What bugs me about a new keyword? One subtle quality (among various) I liked about Zig is that there is kinda mostly / overall / in-spirit one moniker for one underlying-mechanism/operational-semantic, so to speak. Now you'd have to explain in docs/chats/blogs/teaching-materials/talks at length "there are unions, they are like this, then there are structs, they are like that, and btw but there's also another special kind of structs without field names, so there are in addition to unions and structs also tuples but they're really structs under the hood".

PLT folks love the "tuple" moniker but it was always understood that structs/records/classes/tuples are really all primarily one thing, product types. If a struct can have or lack a certain (programmer-facing only, no difference to machine or end user) quality of trivial difference, another keyword for "almost the same thing, except names" might be disproportionate.

[andrewrk]

@metaleap 's ammendum #4335 (comment) is also accepted

[Rocknest]

I don't understand what is being proposed. Is it a special way to declare struct without specifying field names? What is a packed tuple, i can't imagine that, there are no examples to visualise it.

As for use case "emulating multiple returns": i would expect multiple returns to be named, as arguments to a function must have names. e.g:
getPosition() struct {x: f32, y: f32}
divide(num: u64, denom: u64) struct {result: u64, remainder: u64}
getRegs() struct {bp: usize, ip: usize}

Also would anon list literals be coerceable to 'tuples'? @LemonBoy is saying that it should not be allowed #4148 (comment).

[LemonBoy]

I don't understand what is being proposed.

Nor you have understood what I was saying as I was talking about coercing anonymous array literals to named struct literals where you really want to specify what field are you assigning a value to.

[Rocknest]

@LemonBoy your argument that it is a time-bomb does not justify your point, however i understand why it would not be allowed - "favour reading code over writing code"

Edit: how do 'tuples' fit into this zen?

[metaleap]

Edit: how do 'tuples' fit into this zen?

@Rocknest understand this: we already have tuple literals: .{ 10, "20", 3.0 } (that creates under the hood the appropriate struct type with 3 fields named "0" through "2"), just no way to express in code the type of such a thing in current syntax. (For args, vars, consts, fields, you name it.)

The proposal is to have such a facility in the grammar.

[Rocknest]

@metaleap as i said #4335 (comment) i wonder what the use case would be, is that really justified?

[Sobeston]

I feel like a separate key word may cause more confusion than it's worth - new users would likely see it and assume it's a different data structure. I like the idea of making a struct type without specifying field names though ie stuct{u32, []u8}. Nice for function return types. +1

[metaleap]

@Rocknest from my experience in langs that have them (Haskell, C#), unnamed-field "tuples" rarely make it into a somewhat-matured final "production-grade" code product to any great extent. But IMHO they're invaluable just for more-rapidly-iterating alone already, as you restructure fn signatures quickly and re-mold your data/flow structurings at an ideally fast pace. That alone is a valid programmer use-case, making the facility fit for every programming language =)

Commonly seen is also the desire for what's hi-falutingly described as "heterogenous look-and-feel-like arrays" say Vec3[0] through Vec3[2] get accepted by compiler / type-checker, turning into field-accesses, even going as far as allowing loops. I won't argue with that, though in my practice it doesn't really come up.