Hacker News Reader

Comment by db65edfc7996 | Hacker News Reader

Compiler error for unused variables :( [0]. Possibly my most hated feature of Go.

[0] https://ziglang.org/download/0.9.0/release-notes.html#Compil...

Edit: To be clear, love enforcing the idea for production code, but wish they had embraced a '-dev' mode or equivalent flag that made it easier to experiment.

View on HN

One problem I see with this decision is that code will now be littered with:

    _ = bla;
    _ = blub;

...which have been forgotten during development.

So the next thing that's needed is an error if 'bla' or 'blub' are actually used elsewhere ;)

I've been 99% a Go developer since 2015-ish, and this is not something I've ever encountered, in general people just don't leave unused variables lying around. The compile time check does highlight logic errors frequently enough though, so I'm very glad it's there.

More often than not I end up creating variables for a bunch of chained function calls just to get the debugger output right, I might be holding it wrong though.

It's mostly a problem when you're in the middle of writing something and you're trying to figure out what's going wrong, so you start commenting stuff out... And now you have un-used variables that you have to rename to _ for no good reason. It just adds busywork.

It would be nice if Zig had statement- and expression-level comments, similar to how most Lisps let you comment out whole S-exprs (which still have to be valid). Then it could allow variables that are referenced only from such comments.

Sure, but this is an easy thing to audit for (could even be automated as part of some CI system, if you wanted).

Please note there is an accepted proposal[1] to add an unused keyword, making it possible to detect conflicts between things being marked unused and actually being used, and improving tooling integration.

[1]: https://github.com/ziglang/zig/issues/10245

I think there should definitely be a global option to disable this during development. This makes temporarily trying something out (e.g commenting out some code to run only part of it) a massive pain, as you have to go up and edit the variable definition as well as the code using it).

agreed. Rust has a warning for unused items, which is indeed interesting to catch logic errors (variables that should be used, but aren't). No need to fail compilation for this. It is then on you to deny warnings in CI to ensure that they are all handled before the code actually lands

Fully agree. I meet with it mostly in typescript’s linter, but recursively having to comment out things is just simply terrible. Of course it is great for prod, but for debug it is very questionable.

I like this a lot. Though, many pls offer making the identifier start with _ to make it unused well.

I've genuinely never understood this one, especially as a flat-out error instead of a warning. When could not using a variable ever be a bug?

When you mistakenly used the wrong variable name instead, I suppose.

In which case a warning would also do the trick, unless the compiler produces so many warnings that people stop caring.

It is only useful in the very niche case that the incorrect variable name you're using is defined (otherwise you'd get an unknown identifier error) and the correct name you should have been using isn't used anywhere.

Would catch this:

  var a, b
  c = a + a // whoops, should have been a + b, compiler complains about unused b

Doesn't catch this:

  var a, b
  foo(a, b)
  c = a + a // whoops, should have been a + b, but still compiles

All in all, unused variables being errors is an awful feature that isn't very helpful in practice, at the cost of making experimentation a pain in the arse.

There is nothing that kills my state of flow more than having to comment a piece of code that is unreferenced, because the compiler complains, while I'm trying to hack and explore some idea.

It happens. Hell, it even happens in Rust, i had one happen a few weeks ago that the warning lint caught. I had a rename and then added an inner scoped var of the old, previous name - but neglected to use that new var in that inner scope. Compiled fine, but was very much a bug.

Luckily though my Rust setup doesn't fail to compile with unused stuff, it just warns - and then on CI i have it reject all warnings.

I agree it's very frustrating not having a -dev flag or something less restrictive.

That warning has caught bugs for me when I was copy and pasting code, or writing code on "autopilot". Usually it's pretty obvious mistakes though.

Unused variable warnings are a good idea, but making them hard errors is a language design mistake. Warnings are good because they allow programmers to quickly make changes and test things, while providing a reminder to clean things up in the end (which is why the "just use tooling that removes unused variables" response misses the point--when making quick temporary changes for debugging, you want the warnings as reminders to go back and undo the change). Additionally, warnings allow for adding helpful static analyses to the compiler over time without breaking existing code like introducing new errors does. As I recall, there were some cases in which Rust 1.0 accidentally didn't flag unused variables, which was fixable post 1.0 without breaking existing code precisely because it was a warning, not an error.

Pretty bold to call it a language design mistake so confidently, when you have Rust users committing warning-emitting code to their source control.

Does Rust emit warnings for cached compilation units?

Cargo doesn't enable warnings for crate dependencies, by design. In fact, it won't even emit them if those crates say #[deny(warnings)]--there's a special rustc flag called --cap-lints that it uses for this (RFC at [1]). The reason is that a lot of crates say #[deny(warnings)], and this was creating no end of backwards compatibility problems when new warnings were added.

There is an interesting thread with community consensus against the use of #[deny(warnings)] at [2]. The most important takeaway for me is that the right place to deny warnings is in CI. You don't want end users who compile your crate to be have their builds fail due to warnings, because they might be using a newer version of the compiler than you were. You don't want to fail developers' builds due to warnings while hacking on code, because of the overhead warnings-as-errors adds to the edit/compile/debug cycle. CI is the right place to deny warnings, because it prevents warnings from getting to the repository while avoiding the other downsides of warnings-as-errors.

[1]: https://rust-lang.github.io/rfcs/1193-cap-lints.html

[2]: https://www.reddit.com/r/rust/comments/f5xpib/psa_denywarnin...

Yes, users can misuse warnings by ignoring them in CI, but the ergonomic cost of forcing unused variables as errors is disproportionate in regard to this. This affects all users regardless of if they would deny warnings in CI, and leads to either removing/adding some code repeatedly so it compiles at all, or worse adding fake uses, defeating the purpose of the warning. I am using C++ with -Werror during development because it is the only way to keep my sanity (functions not returning a value in C++ is a warning), but it is an ergonomic disaster that I am happy to avoid when using Rust (where the right place to deny warnings is in CI).

I would agree that forcing uninitialised variables as errors is a design mistake.

I think it's reasonable for users to want a workflow that includes some mode where they can temporarily compile code that has unused variable, then check in code that does not have unused variables. The trouble is that if there's such a mode, people will just leave it on permanently. I don't have solutions, but I think it's worth trying to save people's workflows.

    foo := someDefaultValue
    if someCondition {
        foo := someMoreSpecificValue
    }

Whoops, accidentally created a fresh, unused variable in the nested scope instead of changing the value of the original variable.

I do that frighteningly often.

Seems to be more an indication that Go's variable declaration syntax is just not good.

Yeah, var/type name makes much more sense than ambiguity.

I like this feature. It has saved me from annoying bugs multiple times in Go during refactoring.

I love the idea about compiler checking for unused variables in production, and that it's strict and not a warning that can be ignored merrily merrily, gently down the stream! :)

We found a few cases in TigerBeetle where some nasty bugs would have been detected and prevented by this. Some of these were at the entry point to a function, where the function failed to check all the pre-conditions and was ignoring some of the API interface, and others were where we were calculating some of the derived buffers we would need, but then never use them, using the original buffer incorrectly instead.

I tend to prefer a warning rather than a hard error. In CI or a production build, you can make warnings hard errors, but when trying to debug something, you can make temporaries or comment things out as needed

If a local is intentionally unused, it can be discarded, like this:

test "example" {

    var x: i32 = 1234;

    _ = x;

}

Do discards not fulfill your use case?

That is still more movement for when I am hacking out a feature. When I am trying to figure out an idea, I am liberally creating new variables and adding imports without care. In other languages, I can freely comment in/out large swaths of code as I understand the problem.

Not a deal-breaker (honestly, I write Python most days), but a huge annoyance.

Yeah, it's a fair point. Per the zig writeup, the plan / hope for this use case is an editor command that will quickly add in all the "_ = unused" statements, which should take it down to very-small annoyance.

(From my use in Go, I'm definitely overall a fan of the feature. Tho of course how much personal value vs annoyance you get out of it is going to depend on your own code style and behaviors.)

In JavaScript we have a lint for this, so I can run code with unused variables, but I can’t commit code with unused variables (and CI will enforce that for everyone on the team if they bypass the precommit hook). That seems best of both worlds to me.

It might be nicer if the formatter automatically commented out unused stuff, instead of removing it. (As long as it isn’t checked in.)

Reply on news.ycombinator.com