Tips to make temporarily commenting out code for debugging purposes faster?

[modest storm]

I've recently picked up Zig and am really pleased by how fast I could start being productive! One thing that's a bit painful though commenting out some code temporarily because of unused consts and unmutated variables. Take this (unrealistic) example:

fn test(a: f32, b: f32) {
  do_something(a);
  var c = b;
  c += 1;
  do_something(c);
}

If I comment out do_something(a), I have to change a to _, only to change it back right after. If I comment out c += 1;, I have to make c a const.

One trick for commenting out c += 1; without having to make c a const is to just do c = c. Any other tricks like this to facilitate quick experimentation by commenting things out?

Tips to make temporarily commenting out code for debugging purposes faster?

[left glade]

the Zig Language Server has an autofix feature to automatically _ = a; your unused variables

try to see how to enable this in your text editor of choice

in VSCode, the Zig extension exposes this functionality - for other editors someone else will have to fill me in

[void heath]

You can also do _ = &c if c is var instead of const

[lost warren]

and _ = a; instead of changing the name of a

[modest storm]

Oh, the autofix sounds very useful! Thanks for that and the other tips!

Just tried to autofix, seems to work great!

[sleek condor]

I really wish these would just become warnings. Not sure on how that issue is progressing though.

[void heath]

adding warnings would just add a lot of complexity to the project and make it easier for bugs to get into code bases
there arent really any upsides
it really isnt that annoying

[sleek condor]

I disagree, it is extremely annoying, and that's not something we can objectively argue about. I struggle to imagine what sort of bugs would be introduced by fake variability and unused variables?

I have a hunch that more bugs will be introduced and remain in codebases by people applying _ = patterns in quick frustration to get shit to compile and forgetting about it, than if warnings were a thing. It's the same thing with error handling, where everyone just trys everything because they can't be bothered. Compiler happy, but program sucks.

[worn ermine]

regarding fake variability, the compiler can do better optimizations if a variable is const

unused variables are unnecessary computations, so might as well not have them

[sleek condor]

Right, and none of those is some tricky inconceivable bug that's just waiting to bite someone, esp. if there's annoying warnings all over the place

[ornate isle]

I mean the compiler knows if its being used or not (otherwise it wouldnt throw the error). I guess its just a matter of correctness

[void heath]

Warnings dont show up unless that part is analyzed though
Thats the issue
There is no benefit for warnings over errors other than warnings are easier to forget and ignore
Literally just prioritizes the writer's experience over correctness and the reader

[sleek condor]

Errors don't show up either if the part isn't analyzed... so I fail to understand the argument

[void heath]

what?
if theres an error, it wont ever compile
so it will always be analyzed, even when you recompile without changes and even in the future when we have incremental compilation and that part never gets analyzed

[sleek condor]

fn nothingToSeeHere() void {
    const x: bool = 7;
    _ = x;
}

pub fn main() !void {
}

Seems to compile just fine.

[worn ermine]

i dont understand, whats your point with this

[sleek condor]

With this example or with overall whining about this annoying non-feature of Zig?

[worn ermine]

both, but mostly the former

[sleek condor]

The code shows that it's indeed quite possible, and common, to write entirely incorrect Zig code without the compiler saying a word. Thus I fail to understand the argument about warnings not showing up if the code isn't analyzed. Probably I'm missing something, but either way talking about "reader experience" and "correctness" when it's possible to write obviously incorrect Zig without compiler complaining seems moot.

[worn ermine]

discarding a value is not "incorrect"

its a perfectly valid thing to do

_ = argsIterator.skip();
one example of this

[sleek condor]

Not sure we're talking about the same thing. it's const x: bool = 7 that's incorrect in my example.

[worn ermine]

but you discard it. its a misuse, but its still a valid thing to do

[sleek condor]

Which doesn't make much sense. But ok. Perhaps this example is contrived and has some unlikely explanation. I've been hit by this in actual code where I've wrote a lot of functions/methods, without referencing them, and only much later finding out that I've made a bunch of errors, passing wrong arguments to funcs, forgot to do a bunch of casts and what not. So the code looked correct, it happily "compiled", LSP didn't show any errors, but it was still entirely wrong. Something like:

fn add(a: u8, b: u8) u8 {
    return a + b;
}

fn nothingToSeeHere() []const u8 {
    return add("two", "three");
}

pub fn main() !void {
}

[worn ermine]

thats a problem with zls. zls is third-party and honestly kinda sucks

[normal field]

If it was my choise, I'd issues warnings with debug compiles and errors everywhere else. I agree with kvik this error is pain.

[sleek condor]

No. The code above compiles just fine with Zig.

[worn ermine]

i guess it is implicity discarded

if you dont use a function, zig doesnt compile it

[sleek condor]

Yea, warnings on Debug builds for these kinds of minor current errors is exactly what would rock my boat

[worn ermine]

what does this have to do with what you mentioned above though?

this doesnt seem related at all

[sleek condor]

"Warnings dont show up unless that part is analyzed though"

"Literally just prioritizes the writer's experience over correctness and the reader"

[worn ermine]

ok but how is this related to discards and unmutated vars?

[sleek condor]

It's a counter argument to the claim that Zig (apparently) values correctness and reader experience so much that it cannot possibly do anything other than outright error on minor incorrectness of a program such as having an unmutated var.

[scenic knot]

enable build on save and zls will have build errors

[worn ermine]

it doesnt for this

that is not a compile error because the function is unused

[worn ermine]

i see where you are coming from with this. maybe submit a PR or something

discards and non-mutated vars will probbaly not change, but maybe that will

[lost warren]

my understanding is that this is effectively a requirement for conditional compilation to work, e.g.

fn windowsOnly() void {
    const foo = std.os.windows.kernel32.GetProcessHeap();
    // ...
}

if this were analyzed without it being used, it would always cause an error for non-Windows targets

[sleek condor]

That's a good point.

Anyway, I don't intend to push this issue further. Not here and definitely not in a PR. Just pointing out that all the arguments -- other than compiler complexity -- against warnings for mundane problems don't seem to hold water very well.

[worn ermine]

if you wont submit a PR, why are you complaining?

thats not very productive

[sleek condor]

I must have forgot where I signed a document stating I'll be productive at all times. Sorry if I wasted anyone's time, but you could've easily just ignored me, so actually not feeling very sorry 😄

[worn ermine]

i mean its part rule 6 of this server

high quality discussion

[lost warren]

not that a PR would be productive in this scenario either, compile errors for unused variables/unecessary var is one of the most complained about, but least likely to change things in zig

(personally, i like them being errors, but understand why people don't)

[worn ermine]

at least its effort on their part

[lost warren]

effort that would be seen unfavorably if it was brought to the PR queue i'm sure