multiple expression return values, error type redesign, introduction of copyable property of types

[andrewrk]

(see below comment for up to date details of this issue)

struct Foo {
    x: i32,
    y: i32,
}
fn make_foo(x: i32, y: i32) -> Foo {
    var f: Foo = undefined;
    foo.x = x;
    foo.y = y;
    return f;
}
fn f() {
    var foo = make_foo(1234, 5678);
}

When make_foo is generated, we should notice that f is always returned, which means instead of allocating stack space for f, we use the secret first argument pointer value and directly put the values there.

Also, in the code generated for function f, we notice the simple assignment, and instead of doing a memcpy, simply allocate the stack variable for foo, and then call make_foo passing the stack variable address as the secret first parameter.

Once these two optimizations are implemented, idiomatic zig code for initializing structs can be an assignment.

[andrewrk]

This may be more than just an optimization problem. Consider:

pub struct List(T: type) {
    items: []T,
    len: usize,
    prealloc_items: [STATIC_SIZE]T,

    pub fn init() -> List(T) {
        var l: Self = undefined;
        l.items = l.prealloc_items[0...];
        l.len = 0;
        return l;
    }
}

fn basic_list_test() {
    var list = List(i32).init();
    defer list.deinit();
}

Here, we assign a pointer to l.items. The pointer is to the address of prealloc_items, which is on the stack. When we return, this pointer becomes invalid.

Note: I think this is the 2nd time I accidentally did this in the zig standard library, which caused a runtime memory corruption error, which I had to troubleshoot. This is the kind of code we don't want people to write on accident.

If we wanted this to work we would need to make this "return value is on caller's stack" thing more explicit, which I'm not sure we want to do. But it would look something like this:

fn make_foo(x: i32, y: i32) -> (foo: &Foo) {
    foo.x = x;
    foo.y = y;
}

But now this function assumes that there is memory available to write to. If you called the function with no assignment, we'd need a hidden stack allocation (a concept we already have) to provide the memory:

fn f() {
    make_foo(1, 2);
}

Another point is that if we had this different return value syntax, it implies that we should support tuples which is another can of worms. Maybe we should open it.

Let's say we went with this though, and we wanted the instance on the heap:

fn f() {
    const list = alloc_one(List(i32), 1);
    *list = List(i32).init();
}

Kind of awkward. Compare to:

fn heap() {
    const list = alloc_one(List(i32), 1);
    list.init();
}
fn stack() {
    var list: List(i32) = undefined;
    list.init();
}

The latter seems more uniform. Maybe? Now I'm not so sure.

But the point of this comment is that this optimization needs to be explicitly part of the syntax rather than something that sometimes works and is hidden when it doesn't work.

Another option that I am considering is that we could make byvalue struct parameters and return values a compile error. The user would be forced by the compiler to do the undefined/init method, which notably is always available even if we want the other method to be idiomatic. Which means that "only one way to do it" gently suggests disallowing structs as byvalue params and return types.

[fsaintjacques]

var list: List(i32) = undefined;
list.init();

I'd parse this as a null dereference.

[kiljacken]

Well, there no null dereferencing there. Just calling a function on uninitialized stack-allocated struct (which probably passes the struct as a pointer, but it won't be null).
Looks very reasonable to me.

[fsaintjacques]

I am aware there's no null dereferencing. I'm trying to say is that undefined is a really poor keyword name. Maybe adding constructor or initializer, e.g.

var list: List(32) = List(32) { .len = 0, ... };

[kiljacken]

Yeah, undefined seems kind of weirds. As a plain keyword, uninitialized would probably convey the programmer's intent more clearly. I'm not so sure about a constructor/initializer style syntax, as it would require ways both to say: "the rest of the fields are zeroed" and "the rest of the fields are uninitialized".

[fsaintjacques]

Oh no, this is just me being lazy, the initializer list would be forced to put all fields.

[fsaintjacques]

So it does already support the initializer list construct.

[andrewrk]

Equivalent C (ignoring the generic stuff):

List list;
list_init(&list);

Translated to zig:

var list: List = undefined;
list.init();

This looks like a reasonable translation to me.

If it looks bad it's because we're playing with fire by using uninitialized memory. I would argue that your alarm is well deserved. Ideally we would construct the language design so that using undefined is an edge case.

As you mentioned on IRC, something that will help this a bunch is named return value. Then it could look like:

const list = List.init();

Let's look at the proposed initializer syntax:

var list = List(i32) { .len = 0, ... };

Status quo zig says you should write it this way instead:

var list: List(i32) = undefined; // you can also put `zeroes` instead of `undefined`
list.len = 0;

If you want a compile error if a field is added/removed to the struct, then use the initializer list which requires populating all fields (and you can specify some of the fields as undefined or zeroes).

But status quo I think correctly represents the dangers of undefined values.

As for undefined vs uninitialized, it's technically allowed to set something to undefined that was previously defined. This can have implications for optimizations as well as protecting against some mistakes by detecting undefined usage at compile time. Given this it makes more sense to use undefined rather than uninitialized. It makes sense because the compiler requires that variables are initialized to a value, and we tell the compiler that the value is undefined. It's a tad bit higher level of an abstraction as uninitialized. The compiler is allowed to initialize the value if it wants to, and in fact, in debug mode it does exactly that. In debug mode, all undefined bytes are set to 0xaa. Side note, we might want to allow disabling this for the purpose of tools such as valgrind which can emit an error when uninitialized memory is used. Although ideally we would somehow be able to flag this memset in debug info as uninitialized so that valgrind and other tools could track the value as undefined. That would require cooperation/standardization between zig and these other tools though.

[fsaintjacques]

zeroes is a keyword?