Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

self pass by copy copies before arguments are evaluated #22466

Closed
L3nn0x opened this issue Jan 11, 2025 · 1 comment
Closed

self pass by copy copies before arguments are evaluated #22466

L3nn0x opened this issue Jan 11, 2025 · 1 comment
Labels
bug Observed behavior contradicts documented or intended behavior

Comments

@L3nn0x
Copy link

L3nn0x commented Jan 11, 2025

Zig Version

0.13.0 but also trunk on godbolt

Steps to Reproduce and Observed Behavior

Hello,

The following code will return done 0 whereas I would have expected done 1:

const std = @import("std");

const Test = struct {
 value: u8,

 fn inc(self: *Test) bool {
  self.value += 1;
  return true;
 }

 fn get(self: Test, _: bool) u8 {
  return self.value;
 }
};

pub fn main() void {
 var a = Test{.value=0};
 const v = a.get(a.inc());
 std.debug.print("done {}", .{v});
}

I suspect that this is because the self parameter is passed by copy and the copy happens before the arguments are evaluated. Since there is no control over the fact that the struct is passed by copy or by reference, the behavior isn't consistent based on the size of the struct.

A workaround today is to always pass the self argument as a pointer or const pointer.

Godbolt link: https://godbolt.org/z/dTEaPe3d3

Expected Behavior

The struct copy should be done after the arguments are evaluated so the result is done 1 in the example provided.

@L3nn0x L3nn0x added the bug Observed behavior contradicts documented or intended behavior label Jan 11, 2025
@mlugg
Copy link
Member

mlugg commented Jan 12, 2025

Working as intended; evaluation is always left-to-right. The inconsistency based on struct size is going to be fixed by the elimination of PRO's semantic implications (#5973).

@mlugg mlugg closed this as not planned Won't fix, can't repro, duplicate, stale Jan 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Observed behavior contradicts documented or intended behavior
Projects
None yet
Development

No branches or pull requests

2 participants