(Robbie Lyman, that’s me!)
Very nice, this was actually the first “what the hell is going on” bug I ran into when I first learned Zig.
Great work @alanza and Leo! For those curious like myself, here is the PR: https://codeberg.org/ziglang/zig/pulls/36239
I think the post could have a longer introduction, to explain what pointer locks are and why you would want them. The post assumes a lot of knowledge from the reader IMHO, but people like me also wants to know why and when I should need this.
Thanks for the feedback!
std.debug.SafetyLock is implemented as
struct {
state: State = if (runtime_safety) .unlocked else .unknown,
pub const State = if (runtime_safety) enum { unlocked, locked } else enum { unknown };
}
So locking and unlocking is either equivalent to toggling a boolean (with an assertion about its previous state) or a no-op.
I agree that calling them “pointer locks” makes them sound pretty fancy, but as you can see, they’re not. I’m hopeful that if you’re able to bear with me to the example part of the code, you can start to see what they do and why they’re useful, but maybe that didn’t happen.
Very very cool both that @andrewrk invited you to write it via the pull request and that you then did. Excellent stuff all round