Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Doesn't it make it more likely unused variables stay in the codebase? You want to experiment, the code doesn't compile, you add this (probably by automatic tool), the code now compiles. You're happy with your experiment. As the compiler doesn't complain you commit and junk stays in the code.

Isn't it just bad design that makes both experimenting harder and for unused variables to stay in the code in the final version?





It is indeed quite controversial aspect of Zig's design. I would rather prefer it be a warning. Argument "warnings are always ignored" just doesn't hold because anything can be ignored if there is a way to suppress it.

there was a recent interview where andrew suggested if i understood correctly: the future path of zig is to make all compilations (successful or not) produce an executable. if theres something egregious like a syntax or type error, the produced artifact just prints the error and returns nonzero. for a "unused parameter", the compiler produces the artifact you expect, but returns nonzero (so it gets caught by CI for example.

Why would the compiler do that, instead of just printing the error at compile-time and exiting with a non-zero value? What is the benefit?

It is more a debug/development feature. You can try out some idea without fixing the whole code base.

if you have a syntax error in file A, and file B is just peachy keen, you can keep compiling file B instead of stopping the world. Then the next time you compile, you have already cached the result of file B compilation.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: