The C++ standard for the F-35 Fighter Jet [video]

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

Golang is exactly the same.

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

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?

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.

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.

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

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.

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.

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.

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).

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...

> 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".

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.

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.

> 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.

The trick is to have warnings fail CI but not local builds.

> I work with a colleague that doesn't compile/run the code before putting up a MR.

Then erroring on unused variables will not help you anyway.

Anyway, all your issues sound like management problems. Not all projects are run that badly.

> Warnings are often ignored by developers unless you specifically force warnings to be compile errors (you can do this in most compiler).

Not my experience. Find better managers.

> The trick is to have warnings fail CI but not local builds

Which is annoying because the CI pipeline can take like 10 minutes to do the build and then you need to re-commit after turning the warnings on locally.

There are other issue like your code compiles differently in CI vs on your machine, which brings it own issues. Ignored warnings can cause other pieces to fail compilation or execution in other project/libraries. I had this happen in C# and VB.NET.

It is best just to turn on all warnings and errors and be done with it.

I've never heard particularly good reasons for not having it turned on all the time and that includes those mentioned in this thread.

> Then erroring on unused variables will not help you anyway.

The point I am trying to convey, which was a direct response to something the parent said:

"barbarians who commit code that complies with warnings"

IME it is very common for people to just straight up ignore warnings, and issues and sometimes they won't even check the thing compiles. I've worked as a contractor at a number of companies both large and small and this has been a constant.

> Anyway, all your issues sound like management problems. Not all projects are run that badly.

Again the point I was trying to convey is the expectations people have on here are far higher than what some of us have to deal with on a daily basis. So you have to put in loads of automated checks that I don't have to bother with when working with competent people.

>Not my experience

The point being conveyed is your experience is not representative of what commonly occurs. I have worked as a contractor in a number of different orgs both small, large, private and public and more often than not unless you force people to fix these things, they won't.

> Find better managers.

How about you and others with similar attitudes realise that the world isn't perfect and sometimes you have to work with what you got.

Do you think I haven't been looking for a new position? Most of the jobs in my area are going to be more of the same.