4 ms·
> It isn't difficult, but it is friction. Only until getting rid of unused variables becomes a habit before you hit the compiler. Which is a good habit to have
by vanderZwan 4y ago
> It isn't difficult, but it is friction.
Only until getting rid of unused variables becomes a habit before you hit the compiler. Which is a good habit to have anyway.
- rcxdude 4y agoit's still friction when it's a habit, there's a cognitive overhead to tracking that every time you make a change.
- hota_mazi 4y agoGood 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...