Why does destructuring not use temporaries?

[temhelk]

Zig Version

0.12.0-dev.575+fb6fff256

Steps to Reproduce and Observed Behavior

This is more of a question about whether this behavior is correct or not.
It is related to the new feature in this pull request: #17156

I'm using this feature in this case to get a swap-like behavior.

const std = @import("std");

pub fn main() void {
    var a: i32, var b: i32 = .{1, 2};
    std.debug.print("{} {}\n", .{ a, b });

    a, b = .{ b, a };
    std.debug.print("{} {}\n", .{ a, b });
}

This chunk of code prints out the following output:

1 2
2 2

It looks to me like the first assignment 'a = b' happens, and then 'b = a' after that, which would give the same output.

But if we assign '.{ b, a }' to a variable before assignment like here:

const std = @import("std");

pub fn main() void {
    var a: i32, var b: i32 = .{1, 2};
    std.debug.print("{} {}\n", .{ a, b });

    const temp = .{ b, a };
    a, b = temp;
    std.debug.print("{} {}\n", .{ a, b });
}

We would get a different output:

1 2
2 1

And that is what I would normally expect.

Now my question is - should we expect a change in behavior if we temporarily save '.{ b, a }' to a variable?
Should these two outputs be different?

Expected Behavior

Possibly(?) we should expect output to be the same like this in two cases:

1 2
2 1

[rohlem]

Pretty much a duplicate of #12064, although the new syntax certainly makes it even easier to come across.

[andrewrk]

This is working as designed. Everybody was aware this behavior would be a consequence of destructuring and there is no plan to change it.

[Ahmed-0-0]

I noticed that it works as expected when destructuring an array

a, b = [_]i32{b, a}

will eventually output
1 2
2 1

[rohlem]

@0Ahmed-0 I think this is current a remnant of the fact that explicitly specifying the type blocks the result location mechanism, as decided in #17194.
From what I can tell the code still contains the same undefined (illegal?) behavior, meaning the behavior may change at any point.

Explanation of what I think is happening:
Zig introduces a temporary copy early on in its pipeline (done internally to simplify the compiler's implementation).
From Zig's perspective, assignments like this are undefined behavior if you swap values, therefore
it would be allowed to remove the temporary copy as optimization,
meaning it would behave the same as in the original post / when writing .{b, a}.
However, Zig doesn't have any internal optimizations yet, so it never does this.

LLVM (used for optimizations) currently also doesn't optimize it away.
I assume because this is because its optimizations see that doing so would change the behavior,
and it doesn't know that Zig's semantics would allow this optimization (since the code is undefined (illegal?) behavior).

[nektro]

I noticed that it works as expected when destructuring an array

this is great to see but just to clarify where the discrepancy may arise, tuples are structs and so swaps there are assigning to struct fields just as in the issue this is marked as a duplicate of.