remove var args and add anon list initialization syntax

[fsaintjacques]

Accepted Proposal

---

Tuple is a powerful construct in modern language when one doesn't want to define a struct simply to return/pass grouped information. I'd like to be able to do:

val (div, rem) = divWithRemainder(25, 9);

Not sure if this should be part of the language or simply baked in the standard library, e.g like scala where they define Tuple2(inline A: type , inline B: type). They do have sugaring that can extract in the val (x, y) = expr construct though.

[thejoshwolfe]

The topic of tuples was one of the inspirations for the discussion that went into #83 (comment) . Here's what it means for tuples:

Zig is resistant to the idea of having general-purpose tuples simply because they don't seem useful enough to justify including the in the language. But here's what is useful that's like tuples, and we want to include in Zig:

Returning multiple things from a function at once

This is done with named return types. See #83.

Expressions initializing multiple values at once

This is done with all expressions and return types having a number of expressions returned, possibly 0. See #83.

Example:

const a, const b = if (something) {
    1, 2
} else {
    printf("second case\n");
    2, 1
};

Variadic functions (varargs)

See #77.

It's still to be seen how varargs will affect the existence and features of tuples. Maybe we will have tuples as a consequence of the []var type, or maybe not.

[andrewrk]

Proposal: Add tuples and remove var args

Var args turned out to be rather messy and bug prone:

• ability to iterate over a tuple with an inline for loop, when the tuple has runtime fields in it #280
• support comptime for var args parameter #279
• support slicing syntax on var args value #281
• unable to call var args function at compile time #313
• var args can't handle void or number literal arguments #557
• empty string is treated as a void type at compile-time for var args functions #918

Further, it can be abused to achieve default function parameters (rejected in #484) and we don't want that. Even for functions such as std.debug.warn, it is more in the spirit of Zig to pay the cost of a few extra characters of typing in return for the human reading the code to know exactly what's going on at the function definition.

Var args right now is essentially a special-case tuple, with a bunch of arbitrary rules and special cases. So this proposal is to add tuples to the language and remove var args. Calling std.debug.warn would look like this:

pub fn main() void {
    const x: i32 = 1234;
    const y = "aeou";
    std.debug.warn("number: {}, string: {}\n", [x, y]);
}

[a, b, c] is an example of the tuple literal syntax. A trailing comma is optional.

A tuple has comptime-known length (via the .len property) and comptime-known types for each item. The type of each item does not have to be homogeneous, like it does for arrays. The item values are runtime known.

Tuple literals implicitly cast to arrays, when all of the elements of the tuple implicitly cast to the array type, and the length matches.

I also propose @call which can be used to "explode" a tuple into the function arguments: @call(function, tuple). foo(x, y, z) would be equivalent to @call(foo, [x, y, z]).

The syntax for a tuple type is tuple{T1, T2, T3}

The definition of a function which accepts a tuple as an argument would likely use var:

fn print(comptime format: []const u8, args: var) void {
    inline for (args) |arg| {
        // `for` works with tuples
    }
}

You would need the var because you want to accept a tuple{i32, []const u8} as well as tuple{i32, i32, f32}, etc.

Here's an example from another issue, division that wants to report error.DivisionByZero:

fn div(numerator: i32, denominator: i32) !tuple{i32, i23} {
    if (denominator == 0) return error.DivideByZero;
    // ...
    return [a, b];
}

One more note on the literal syntax. I have an idea for an untyped struct literal that would look like (notice the dot in front):

.{.field = value, .field2 = value2}

This is to match untyped enum literal syntax, useful in switch cases:

.EnumValue

If we kept these in mind, then it might make sense, instead of [x, y, z] to use .{x, y, z} for tuple literal syntax.

Tuple instances can be accessed with array access syntax: a_tuple[0], a_tuple[1], ...