Side effects of function analysis should be applied at the call site

[tiehuis]

Edit: Original title was "Add compiler error for comptime pointer parameter with side-effects". The correct behavior is described in this comment.

---

const warn = @import("std").debug.warn;

fn inc(comptime foo: *usize) void {
    foo.* += 1;
}

pub fn main() void {
    comptime var bar: usize = 0;
    inc(&bar);
    warn("{}\n", bar);
}

This outputs 0 which is unexpected behavior to me. I would have expected the inc call would implicitly be called at compile-time.

Explicitly calling the function at comptime resolves this. This isn't a suitable workaround for me unfortunately since I'm actually passing varargs as well which do not work at comptime.

const warn = @import("std").debug.warn;

fn inc(comptime foo: *usize) void {
    foo.* += 1;
}

pub fn main() void {
    comptime var bar: usize = 0;
    comptime inc(&bar);
    warn("{}\n", bar);
}

I presume the compiler doesn't see that inc has side-effects for its input, and the runtime call simply becomes an empty function after it is resolved. Thinking a bit more, I think the existing behavior is correct, and it is more the lack of a compiler error which is the issue.

A workaround is to avoid comptime pointer parameters and return the values as needed. This correctly catches the issue with a compiler error.

const warn = @import("std").debug.warn;

fn inc(comptime foo: usize) usize {
    return foo + 1;
}

pub fn main() void {
    comptime var bar: usize = 0;
    bar = inc(bar);
    warn("{}\n", bar);
}

$ zig run t.zig 
/tmp/t.zig:9:9: error: cannot store runtime value in compile time variable
    bar = inc(bar);
        ^

May be fundamentally the same as #906.

[tiehuis]

I note above that this wasn't a workaround for me, but I can restructure to avoid comptime varargs and thus work around this so this shouldn't block me on anything.

[ghost]

Hang on now. #5675 presents a use case for comptime mutable pointer arguments. I don't think we should be so heavy-handed.

[SpexGuy]

We discussed this in a design meeting and decided that, anywhere observable, functions which mutate comptime state through pointers should behave as if they were analyzed at the call site. So in the following example:

const warn = @import("std").debug.warn;

fn inc(comptime foo: *usize) void {
    warn("{}\n", foo.*);
    foo.* += 1;
}

pub fn main() void {
    comptime var bar: usize = 0;
    inc(&bar);
    inc(&bar);
    bar += 1;
    warn("{}\n", bar);
}

The first call to inc is analyzed immediately, generates code to print 0, and increments bar to 1. It isn't cached because it modifies a comptime var.
The second call to inc is also analyzed immediately, generates code to print 1, and increments bar to 2. Again, it's not cached.
Finally, bar is incremented within main and becomes 3. Then code for the last warn is generated to print 3.

So in short, it behaves the way you wanted it to when you first wrote the code.

[andrewrk]

functions which mutate comptime state through pointers

I want to point out that the language spec already requires this concept, in order to detect when to not memoize comptime function calls. Memoizing comptime function calls is necessary for functions that return types to work properly, e.g. ArrayList(i32). Not memoizing comptime function calls that mutate comptime state is then required to uphold other properties of the language. Anyway long story short, this solution is not inventing a special concept just to tackle the problem; it is re-using an existing concept to also address this.