Good habit, maybe, but it shouldn't cause a compilation failure.
Add to that the snowball effect: you comment out a variable, compile, and you get another error because commenting out variable a made variable b unused. Rinse and repeat.
It's a huge and totally unnecessary time sink.
It should be opt-in, so that it's a warning by default, and then, when I'm ready to push my code, I could run some --strict mode that would force me to clean up my code.
One of the features in go that makes it workable is you can assign it away via:
_ = somevar
That eliminates the unused chain problem. Not sure if zig included that part of the feature as well.
Generally I agree though. The main problem with forcing unused variables, imo, is that it forces you to think a certain way. When I'm exploring the solution space on something, those constraints feel inhibiting.
If one suggested this in any other language to suppress "unused variable" warnings it would be considered a lazy way to avoid fixing the issue.
Meanwhile the developer of Zig himself recommended doing this[0] which only shows what a bad idea it is to make this a compiler error imho. It encourages workarounds and enforces something we automated long ago in the form of dead code elimination.
Add to that the snowball effect: you comment out a variable, compile, and you get another error because commenting out variable a made variable b unused. Rinse and repeat.
It's a huge and totally unnecessary time sink.
It should be opt-in, so that it's a warning by default, and then, when I'm ready to push my code, I could run some --strict mode that would force me to clean up my code.