Skip to content

Proposal: Make comptime var convert to runtime var when modified at runtime #9898

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

Closed
Matceporial opened this issue Oct 5, 2021 · 7 comments
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@Matceporial
Copy link

Matceporial commented Oct 5, 2021

This also solves #1470, #906 and #7396, while being better at preserving variable semantics

comptime var a = 0;
a += 1;
if (runtime_condition) {
  a += 1;
} else {
  a += 2;
}
a += 1;
comptime {
  a += 1;
}

becomes equivalent to

var a = 1;
if (runtime_condition) {
  a += 1; // this lines makes it become runtime
} else {
  a += 2;
}
a += 1;
comptime {
 a += 1; // error from modifying a runtime var at comptime
         // maybe include reference to the line that made it runtime
}

Essentially, a comptime variable is converted into a runtime var with its last comptime value at the instantiation site if it is modified at runtime.
#7396 becomes the same as closing over a runtime var.

@SpexGuy
Copy link
Contributor

SpexGuy commented Oct 5, 2021

How does this interact with pointers and addressof (&)?

@Matceporial
Copy link
Author

Matceporial commented Oct 5, 2021

How does this interact with pointers and addressof (&)?

Should be same as storing into runtime variable and using that. Maybe we can add some special cases for pointers (e.g convert to const ptr when out of scope), maybe not

@ghost
Copy link

ghost commented Oct 5, 2021

I'm not sure I see the benefit of this. Throwing an error when a comptime var is modified at runtime looks like reasonable behavior to me. Why would we want to silently throw out the comptime annotation instead? Actually, what would be the point of making a variable comptime at all?

@Matceporial
Copy link
Author

I'm not sure I see the benefit of this. Throwing an error when a comptime var is modified at runtime looks like reasonable behavior to me. Why would we want to silently throw out the comptime annotation instead? Actually, what would be the point of making a variable comptime at all?

The comptime annotation is not thrown out, the variable is comptime until it is runtime modified, that is it can do comptime work until the first run-time modification to it, so the point of it being comptime remains until you try to modify it at runtime. The point of placing the last comptime value at the instantiation site is for scoping runtime access to it the same way as for runtime variables, rather than the current situation of closing over it (#7396) in a broken way.

@SpexGuy
Copy link
Contributor

SpexGuy commented Oct 6, 2021

So what would this program do?

const std = @import("std");
pub fn main() void {
  var x: u32 = 0;
  const px = &x; // x is not yet modified, what does this point to?
  if (runtime_cond) x += 1; // conditionally modify x
  const px2 = &x; // x is definitely runtime now
  std.debug.print("ptrs_eql={}, vals_eql={}\n", .{ px == px2, px.* == px2.* });
}

@ghost
Copy link

ghost commented Oct 6, 2021

@Matceporial
Thanks for the explanation. I missed the "with the last comptime value" part.

Edit: But my other point still stands: With this change, what is the point of a comptime annotation for vars? In principle, all vars could be comptime until they become runtime.

@Jarred-Sumner
Copy link
Contributor

Jarred-Sumner commented Oct 6, 2021

Personally, when I explicitly use comptime, I want it to error if it cannot be comptime – the intent is to ensure the code does not execute at runtime.

@andrewrk andrewrk added the proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. label Nov 20, 2021
@andrewrk andrewrk added this to the 0.9.0 milestone Nov 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests

4 participants