use case: initialize struct with one field pointing to another

[andrewrk]

const array_of_things = []Thing {
    foo(),
    foo(),
};

struct Thing {
    field1: &i32,
    field2: i32,
}

fn foo() -> Thing {
    Thing {
        field1: // somehow make this reference field2
        field2: 1234,
    }
}

[kiljacken]

Correct me if I'm wrong, but this would only be useful for structs that can be guaranteed to be at a certain address at compile time (e.g. const at top-level of a module), right? I'm just trying to wrap my head around this.

[andrewrk]

Correct. It is a bit error prone, since the reference becomes invalid if you use byval struct assignment. But it is possible to generate such static data structures, so it should arguably be expressible in zig.

[andrewrk]

Maybe #169 could help:

fn foo() -> Thing {
    Thing {
        field1: &this.field2,
        field2: 1234,
    }
}

There's still a problem to solve here, however. In general, fields which point to other fields in a struct are pointing to an address on the stack, which becomes invalid when the function returns a struct byval. We're actually considering making it a compile error to pass or return structs or other large objects by value.

This is where the abstraction of executing code at compile time gets a bit leaky, because it actually does make sense to return a struct byval if the function runs at compile time.

This is maybe another hint that the following syntax for return values might be better (explicit naming of return value storage):

fn foo() -> (result: &Thing) {
    result.field1 = &result.field2;
    result.field2 = 1234;
}

Another idea I had just now is that we can have copying structs be a compile error by default. In order to allow structs to be mem copied or byvalue assigned, you'd have to add #attribute("copyable") to the struct. Or maybe the other way around, you could add #attribute("no-copy") to have copying memory bytes be a compile error.

This way when you have a struct more complicated than Plain Old Data, you can be sure that nobody accidentally copies the memory thinking that the new memory will be valid.

There should be a way to override this safety check when necessary. Maybe the struct's own copy implementation is aware of the issues with copying and knows to patch up the incorrect fields after doing a mem copy.

[thejoshwolfe]

After having dealt with C++ default copy constructors, I'd advocate for no-copy being the default, and needing to specify #attribute("copyable"), which in C++ terms would generate a copy constructor that simply assigns each element.

If we define "copying" as recursively copying each element (as opposed to jumping straight to memcpy), then the no-copy restriction is contagious to any struct containing a no-copy struct, which is probably what we want.

[andrewrk]

Sounds good.

I think we can get away with defining these semantics while still having it codegen to a memcpy.

[daurnimator]

Related to #591 (comment)

[thejoshwolfe]

This use case is solved by the result location semantics proposed in #2765 and this code:

const Thing = struct {
    field1: &i32,
    field2: i32,
};

fn foo() -> Thing {
    var result = Thing{
        .field1 = undefined,
        .field2 = 1234,
    };
    result.field1 = &result.field2;
    return result;
}