Zig makes it explicit with

    _ = a;

And you would encounter it quite often because unused variable is a compilation error: https://github.com/ziglang/zig/issues/335

▲ bluecalm a day ago | parent | next [-]

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.

▲ ErroneousBosh a day ago | parent | prev [-]

Golang is exactly the same.

It's extremely annoying until it's suddenly very useful and has prevented you doing something unintended.

▲

bluecalm a day ago | parent | next [-]

I fail to see how a warning doesn't achieve the same thing while allowing you to iterate faster. Unless you're working with barbarians who commit code that complies with warnings to your repo and there is 0 discipline to stop them.

▲

FieryMechanic 14 hours ago | parent | next [-]

> I fail to see how a warning doesn't achieve the same thing while allowing you to iterate faster.

In almost every code base I have worked with where warnings weren't compile errors, there were hundreds of warnings. Therefore it just best to set all warnings as errors and force people to correct them.

> Unless you're working with barbarians who commit code that complies with warnings to your repo and there is 0 discipline to stop them.

I work with a colleague that doesn't compile/run the code before putting up a MR. I informed my manager who did nothing about it after he did it several times (this was after I personally told him he needed to do it and it was unacceptable).

This BTW this happens more often than you would expect. I have read PRs and had to reject them because I read the code and they wouldn't have worked, so I know the person had never actually run the code.

I am quite a tidy programmers, but it difficult for people even to write commit messages that aren't just "fixed bugs".

	▲	ErroneousBosh 5 hours ago \| parent [-]
		> I work with a colleague that doesn't compile/run the code before putting up a MR. I informed my manager who did nothing about it after he did it several times (this was after I personally told him he needed to do it and it was unacceptable). At this point what you need to do is stop treating compiler warnings as errors, and just have them fire the shock collar. Negative reinforcement gets a bad rep, but it sure does work.

▲

ErroneousBosh 17 hours ago | parent | prev | next [-]

Go is a very opinionated language. If you don't like K&R indentation, tough - anything else is a syntax error.

It's kind of like the olden days.

▲

bluecalm 16 hours ago | parent [-]

Yeah but this case just seem to be strictly worse. It makes experimenting worse and it makes it more likely (not less) that unused variables end up in the final version. I get being opinionated about formatting, style etc. to cut endless debates but this choice just seem strictly worse for two things it influences (experimenting and quality of the final code).

	▲	ErroneousBosh 16 hours ago \| parent [-]
		If you want to leave a variable unused, you can just assign it to _ (underscore) though. IIRC gofmt (which your editor should run when you save) will warn you about it but your code will compile. It's a slightly different mindset, for sure, but having gofmt bitch about stuff before you commit it rather than have the compiler bitch about it helps you "clean as you go" rather than writing some hideous ball of C++ and then a day of cleaning the stables once it actually runs. Or at least it does for me...

▲

treyd 19 hours ago | parent | prev [-]

You're not supposed to question the wisdom of the Go developers. They had a very good reason for making unused variables be an unconfigurable hard error, and they don't need to rigorously justify it.

	▲	FieryMechanic 14 hours ago \| parent [-]
		Warnings are often ignored by developers unless you specifically force warnings to be compile errors (you can do this in most compiler). I work on TypeScript/C# code-bases and unless you force people to tidy up unused imports/using and variables, people will just leave them there. This BTW can cause issues with dependency chains and cause odd compile issues as a result.

▲

SoKamil a day ago | parent | prev [-]

And what is the unintended thing that happens when you have unused variable?