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?

▲

ivanjermakov a day ago | parent [-]

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.

▲

dnautics a day ago | parent [-]

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.

▲

sumalamana a day ago | parent [-]

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?

	▲	dnautics 10 hours ago \| parent \| next [-]
		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.
	▲	j16sdiz 21 hours ago \| parent \| prev [-]
		It is more a debug/development feature. You can try out some idea without fixing the whole code base.