3 ms·
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 erro
by hota_mazi 4y ago
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.
- NyxWulf 4y agoOne 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.
- alpaca128 4y ago> you can assign it away via: _ = somevar 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. [0] https://github.com/ziglang/zig/issues/335#issuecomment-435267965 https://github.com/ziglang/zig/issues/335#issuecomment-43526...
- hactually 4y agoIt's how Go works...