Ugh. This is something I hate about Go. I would be happy to have unused variables generate warnings, but as errors, they turn the toolchain into an adversary.
It's common for me to temporarily comment out a variable's use when developing new code, as I experiment with ideas. It's even more common when working in unfamiliar code, such as tracking down a bug or incrementally adding a new feature. It's an important part of my exploration process.
When I hit Compile at that point, I expect the compiler to build the work-in-progress exactly as it is in that moment. Executing the output allows me to spot check the snapshot's behavior against my expectations and mental model. The compile step also assures me that no syntax errors have crept in while I was focused on the logic flow or general shape of the code.
When a compiler refuses to do its job, and instead barfs up spurious errors complaining about unused variables, it brings my workflow to a screeching halt. In order to make progress, I am forced to abruptly leave my current context to visit all the different places where those variables are introduced, edit them, try again, discover that those forced edits have left more variables unused, and repeat the process until the combative compiler shuts up and does what I told it to do in the first place. By the time I'm allowed to return to what I was doing, my train of thought has been derailed, the bits of logic that I had been juggling have fallen to the ground, and my focus destroyed. And then, once I have recovered my original thoughts and seen the output of my snapshot build, I have to go back and revert all those forced edits before I can resume my work.
What an aggravating, disruptive, and completely unnecessary waste of my time and attention.
I hope Andrew has the good sense to let errors of this kind be silenced or demoted to warnings, perhaps with a compiler flag or debug build mode.
Yeah it drives me insane. Working in any ide's golang lsp/plugin that tries to solve this for you every time you hit save also drives me insane. Feel like something is lost experiencing/learning/becoming masterful at a language when these types of decisions get automated while you're hand crafting.
I actually really valued my exploration into C where if i did that, id get a fat warning on compile, but I could still proceed to test my stuff. When I'm ready to commit to some cleanup efforts which is usually a headspace-thing, then I go cruise around and cleanup unused variables.
Well its also just idiotic in terms of how some huge number of people write code.
I know I'll need so-and-so import, so i write it at the top of the file before i even start, I press ctrl-s and it dissapears... I honestly laughed out loud the first time i used gopls.
I love Zig and I am generally very happy with Andrew's benevolent dictatorship and the benefits of having one single smart tasteful person in charge of decisions, but the unused variable one really hurts. My guess is that he's seen what a mess C code can be with regard to warnings and so is just totally unwilling to compromise by adding the concept of warnings to Zig. But if I had one wish about the language, it would be for a command-line flag to disable unused variable errors. So much effort has been put into making iteration fast (all this build system stuff, the custom backend, incremental compilation) and then there's just this giant blocker preventing fast iteration on the editing side.
The converse is that if you have many unused variables some of them are used in some contexts but not others and then when you use FIND to find occurrences of a variable you will find many which are not relevant and some which are.
Overall the code gets smaller and easier to understand when it only has things that need to be there. If you comment out a an unused variable you can see from find-results that in effect that occurrence cannot matter.
Unused variables are "noise" that hide actually important things.
If they wanted the release build to be an error I wouldn't care. Having the current solution be "have the editor automatically change code to include or remove the underscore" is so wrong to me. Just invented a problem that needs tooling to modify source code to fix.
So your ice turns 'let unused = func();' into 'let _ = func();' automatically? Okay but then do I later have to grep for 'let _' to find all these unused variables and delete them? This is silly and a has consequence of zig not having any system for warnings
as a fan of him this rationale did not make a shred of sense
"Both parties can have their preference" - this was already true of C where you can just turn enable unused variable warnings or turn them into hard errors, this has nothing to do with the decision.
I also don't want my lsp randomly rewriting my code (???)
In rust, having unused variables as a warning (but not an error) let's you refactor code, test it and see what is now unused as a result. You can then remove the unused items. Zig requires you to remove the unused items (e.g. with '_ = ...;' which is then something you might forget about) before testing, increasing friction.
Multiline comments are less important, but its still convenient for commenting out large chunks of code. IDEs make this a bit easier when you can press e.g. Ctrl+/ to comment out the selected lines with //, but it doesn't work in all cases.
The friction stops zig from being fun imo. A shame because I really like comptime.
Thanks, there is always a risk of people jumping on replies like that to scream that you are doing it wrong. I just wanted to see how other people do stuff. Hope everyone stays nice.
Not the person you replied to but I leave unused variables as future TODOs. It's a warning in F#. I also often use them for inspecting data in the debugger
Ugh. This is something I hate about Go. I would be happy to have unused variables generate warnings, but as errors, they turn the toolchain into an adversary.
It's common for me to temporarily comment out a variable's use when developing new code, as I experiment with ideas. It's even more common when working in unfamiliar code, such as tracking down a bug or incrementally adding a new feature. It's an important part of my exploration process.
When I hit Compile at that point, I expect the compiler to build the work-in-progress exactly as it is in that moment. Executing the output allows me to spot check the snapshot's behavior against my expectations and mental model. The compile step also assures me that no syntax errors have crept in while I was focused on the logic flow or general shape of the code.
When a compiler refuses to do its job, and instead barfs up spurious errors complaining about unused variables, it brings my workflow to a screeching halt. In order to make progress, I am forced to abruptly leave my current context to visit all the different places where those variables are introduced, edit them, try again, discover that those forced edits have left more variables unused, and repeat the process until the combative compiler shuts up and does what I told it to do in the first place. By the time I'm allowed to return to what I was doing, my train of thought has been derailed, the bits of logic that I had been juggling have fallen to the ground, and my focus destroyed. And then, once I have recovered my original thoughts and seen the output of my snapshot build, I have to go back and revert all those forced edits before I can resume my work.
What an aggravating, disruptive, and completely unnecessary waste of my time and attention.
I hope Andrew has the good sense to let errors of this kind be silenced or demoted to warnings, perhaps with a compiler flag or debug build mode.