6 ms·

Compiler error for unused variables :( [0]. Possibly my most hated feature of Go. [0] https://ziglang.org/download/0.9.0/release-notes.html#Compile-Errors-for-

Compiler error for unused variables :( [0]. Possibly my most hated feature of Go. [0] https://ziglang.org/download/0.9.0/release-notes.html#Compile-Errors-for-Unused-Locals 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.

ryanworl 5y ago
I like this feature. It has saved me from annoying bugs multiple times in Go during refactoring.
- deleted 5y ago
  [deleted]
jimbob45 5y ago
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?
- deleted 5y ago
  [deleted]
- db65edfc7996 5y ago
  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.
  - dilap 5y ago
    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.)
    - nicoburns 5y ago
      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.
flohofwoe 5y ago
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 ;)
- mediocregopher 5y ago
  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.
  - lillecarl 5y ago
    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.
  - DangitBobby 5y ago
    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.
    - int_19h 5y ago
      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.
- dilap 5y ago
  Sure, but this is an easy thing to audit for (could even be automated as part of some CI system, if you wanted).
- 5y ago
nauticacom 5y ago
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?
- macintux 5y ago
  When you mistakenly used the wrong variable name instead, I suppose.
  - alpaca128 5y ago
    In which case a warning would also do the trick, unless the compiler produces so many warnings that people stop caring.
  - 1_player 5y ago
    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.
- lijogdfljk 5y ago
  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.
- pcwalton 5y ago
saghm 5y ago
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
deleted 5y ago
[deleted]
skybrian 5y ago
It might be nicer if the formatter automatically commented out unused stuff, instead of removing it. (As long as it isn’t checked in.)
Shadonototra 5y ago
_vvhw 5y ago
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.

ryanworl 5y ago

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

deleted 5y ago
[deleted]

jimbob45 5y ago

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?

deleted 5y ago
[deleted]
db65edfc7996 5y ago
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.
- dilap 5y ago
  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.)
  - nicoburns 5y ago
    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.

flohofwoe 5y ago

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

mediocregopher 5y ago
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.
- lillecarl 5y ago
  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.
- DangitBobby 5y ago
  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.
  - int_19h 5y ago
    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.
dilap 5y ago
Sure, but this is an easy thing to audit for (could even be automated as part of some CI system, if you wanted).
5y ago

nauticacom 5y ago

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?

macintux 5y ago
When you mistakenly used the wrong variable name instead, I suppose.
- alpaca128 5y ago
  In which case a warning would also do the trick, unless the compiler produces so many warnings that people stop caring.
- 1_player 5y ago
  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.
lijogdfljk 5y ago
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.
pcwalton 5y ago

saghm 5y ago

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

deleted 5y ago

[deleted]

skybrian 5y ago

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

Shadonototra 5y ago

_vvhw 5y ago

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.