Temporarily allow unused variables

[Elazar Leibovich]

I sometimes have a very strange error, which I can't understand its source.

One of my techniques for finding it, is isolate the problem to a very small case, by commenting out pieces of the code, and noticing which pieces of codes cause the problem.

Go really helps me with it due to the short compile run cycles, but it is very difficult to use this technique without leaving unused variables.

Is there a flag that enables you to temporarily compile without this warning?

[Peter Bourgon]

+1.

(And "imported but not used" errors.)

[John Barham]

> Is there a flag that enables you to temporarily compile without this
> warning?

No. It's a FAQ:
http://weekly.golang.org/doc/go_faq.html#unused_variables_and_imports

[Miguel Pignatelli]

> Is there a flag that enables you to temporarily compile without this
> warning?

No, there is not such an option. It has been discussed several times in
this list.

You can use the blank identifier to avoid this issue:

To avoid unused imports:

var _ = fmt.Printf // package fmt is now used

To avoid unused variables:

var _ = foo // foo is now used

These changes have little impact in the rest of the code

M;

[Elazar Leibovich]

On Wednesday, March 7, 2012 1:58:45 PM UTC+2, emepyc wrote:

> Is there a flag that enables you to temporarily compile without this
> warning?

No, there is not such an option. It has been discussed several times in
this list.

I searched the list, and didn't find discussion about unused variables as temporary debugging aid. I apologize.

 

You can use the blank identifier to avoid this issue:

I'm well aware of this solution, however, in a situation like I described, you're often not sure what will you remove next. It creates extra work for generating this blank identifiers for each and every unused variables.

The worst part about them, is that you might leave some behind, when finished debugging.

While I can understand the purist POV of the FAQ (compiler flags should not affect semantics), it doesn't aid me with my debugging. I don't care about unused variables per se, I'll be glad to see any other solution to help me use my aforementioned debugging technique.

[roger peppe]

i use this technique too (doesn't everyone?) and find that the
"missing variables" error is actually useful as it forces
me to clean up the code as i'm going along, which can
make the bug stand out better.

[Michael Jones]

Not a flag, but inserting the text "continue;" at line 93 of
src/cmd/gc/walk.c seems to have the effect you speak of...

>> Is there a flag that enables you to temporarily compile without this
>> warning?

--
Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1
650-335-5765

[betamos]

+1

One of the reasons I really like Go is the pragmatic approach to
programming, to just get shit done!

The lack of warnings slows down development and many people have
already complained about it. And if it's worth complaining about, it's
worth fixing, right?

[Aram Hăvărneanu]

> The lack of warnings slows down development and many people have
> already complained about it.

How can the lack of warnings slow down development?

--
Aram Hăvărneanu

[chris dollin]

On 23 March 2012 08:20, Aram Hăvărneanu <ara...@mgk.ro> wrote:
>> The lack of warnings slows down development and many people have
>> already complained about it.
>
> How can the lack of warnings slow down development?

Because unused variables are errors, so you /have/ to do something
to your code to squelch them, rather than sorting out whatever
your current problem is -- after which there will likely be no
unused variables left, problem solved.

So it is said, and I have sympathies for this argument.

Chris

--
Chris "allusive" Dollin

[Jan Mercl]

On Friday, March 23, 2012 9:27:17 AM UTC+1, ehedgehog wrote:

On 23 March 2012 08:20, Aram Hăvărneanu wrote:
>> The lack of warnings slows down development and many people have
>> already complained about it.
>
> How can the lack of warnings slow down development?

Because unused variables are errors, so you /have/ to do something
to your code to squelch them, rather than sorting out whatever
your current problem is -- after which there will likely be no
unused variables left, problem solved.

Because unused variables are errors I *have* to do something to my code to squelch them (before the compiler accepts is), so I must sort out what problem my code has (right now, when I freshly wrote it and not a year later) -- after which there will be no unused variables left, problem solved.

 

So it is said, and I have sympathies for this argument.

That said, I have sympathies for the current state.

PS: Yes, I believe warnings in this case would only slow down my development productivity both in the average of the long run and also right now as they would allow me to postpone the problem to a point when it's harder to solve it. 

[Elazar Leibovich]

On Fri, Mar 23, 2012 at 10:59 AM, Jan Mercl <0xj...@gmail.com> wrote:

PS: Yes, I believe warnings in this case would only slow down my development productivity both in the average of the long run and also right now as they would allow me to postpone the problem to a point when it's harder to solve it. 

Warnings is not the only solution for this problem, I'm fine with having unused variables as errors by default. However for some use cases, such the one I described, it makes sense to have an option to, say, go build --force, that would ignore errors when it makes sense. Sometimes, by the time you remove the unused variables error, you could have verify these lines aren't the source of your bug, and comment them in again. Also not having "go build --force" encourages you to add things like "var _ = a" to your code base. You can easily forget to remove this statement, and then have unused variables in your production build.

The FAQ oppose this problem from a purist POV, "flags should not change the semantics of the compiler", I don't see any practical damage it might cause. However, this POV does not help me as a practitioner to find my bugs faster in a certain use cases.

[chris dollin]

On 23 March 2012 08:59, Jan Mercl <0xj...@gmail.com> wrote:
> On Friday, March 23, 2012 9:27:17 AM UTC+1, ehedgehog wrote:
>>
>> On 23 March 2012 08:20, Aram Hăvărneanu wrote:
>>
>> >> The lack of warnings slows down development and many people have
>> >> already complained about it.
>> >
>> > How can the lack of warnings slow down development?
>>
>> Because unused variables are errors, so you /have/ to do something
>> to your code to squelch them, rather than sorting out whatever
>> your current problem is -- after which there will likely be no
>> unused variables left, problem solved.
>
> Because unused variables are errors I *have* to do something to my code to
> squelch them (before the compiler accepts is), so I must sort out what
> problem my code has (right now, when I freshly wrote it and not a year
> later)

... and it is this process that introduces the (temporarily) unused
variables and causes the compiler to put your brakes on.
At this point, dealing with unused variables is make-work,
not productive effort.

I don't want to export code with unused variables past this
work session. But I don't want to be sticking in assigments
to _ or commenting out imports or deleting swathes of code
/just/ to deal with a problem that will almost certainly deal
with itself in the next ten minutes.

[Jan Mercl]

On Friday, March 23, 2012 10:06:18 AM UTC+1, Elazar Leibovich wrote:

On Fri, Mar 23, 2012 at 10:59 AM, Jan Mercl wrote:

PS: Yes, I believe warnings in this case would only slow down my development productivity both in the average of the long run and also right now as they would allow me to postpone the problem to a point when it's harder to solve it. 

Warnings is not the only solution for this problem, I'm fine with having unused variables as errors by default. However for some use cases, such the one I described, it makes sense to have an option to, say, go build --force, that would ignore errors when it makes sense. Sometimes, by the time you remove the unused variables error, you could have verify these lines aren't the source of your bug, and comment them in again. Also not having "go build --force" encourages you to add things like "var _ = a" to your code base. You can easily forget to remove this statement, and then have unused variables in your production build.

_ = a // is shorter

And still I wouldn't recommend doing this. Just fix the error. Now, not later.

 

The FAQ oppose this problem from a purist POV, "flags should not change the semantics of the compiler", I don't see any practical damage it might cause. However, this POV does not help me as a practitioner to find my bugs faster in a certain use cases.

It seems to me that I get an "unused variable" error at a reasonably low rate, usually right after adding a new func/method (followed habitually by a test drive compiling of the package only to check the compiler can still cope with it) when I make a silly logic/typing error. Then such error is welcome and it's fixed most times within seconds. But I appreciate I'm effectively forced to make the fix immediately and not allowed to be lazy now - at the cost of future headaches ;-)

[Jan Mercl]

On Friday, March 23, 2012 10:20:43 AM UTC+1, ehedgehog wrote:

On 23 March 2012 08:59, Jan Mercl wrote:
> Because unused variables are errors I *have* to do something to my code to
> squelch them (before the compiler accepts is), so I must sort out what
> problem my code has (right now, when I freshly wrote it and not a year
> later)

... and it is this process that introduces the (temporarily) unused
variables and causes the compiler to put your brakes on.
At this point, dealing with unused variables is make-work,
not productive effort.

I don't get it. Say, if I assign to a variable and never read it - that produces a compiler error. I realize I completely missed a line of code on it s way from my head to the editor. I don't "fix" it by _ = v, but by making the code correct - adding the omitted piece of code. I think that's productive, not make-work.

In the specific case of debugging by commenting lines this may interfere with the positive value seen above, but still it's IMO not a good idea to add such compiler switch only for this corner case. Debug printing, using a debugger (has anyone other tried how nice is debugging with Clewn and Go?) are viable options too.

[chris dollin]

On 23 March 2012 09:24, Jan Mercl <0xj...@gmail.com> wrote:

> It seems to me that I get an "unused variable" error at a reasonably low
> rate, usually right after adding a new func/method (followed habitually by a
> test drive compiling of the package only to check the compiler can still
> cope with it) when I make a silly logic/typing error. Then such error is
> welcome and it's fixed most times within seconds. But I appreciate I'm
> effectively forced to make the fix immediately and not allowed to be lazy
> now - at the cost of future headaches ;-)

I usually get them when I'm modifying existing code and
wish to put in debugging prints or alternative paths,
where the variables [or package names] may dance in
and out of usedness as I work out what's going on.

EG the fmt dance where `import "fmt"` comes and goes as
fmt.PrintXXX calls appear and disappear.

[Elazar Leibovich]

On Fri, Mar 23, 2012 at 11:24 AM, Jan Mercl <0xj...@gmail.com> wrote:

The FAQ oppose this problem from a purist POV, "flags should not change the semantics of the compiler", I don't see any practical damage it might cause. However, this POV does not help me as a practitioner to find my bugs faster in a certain use cases.

It seems to me that I get an "unused variable" error at a reasonably low rate, usually right after adding a new func/method (followed habitually by a test drive compiling of the package only to check the compiler can still cope with it) when I make a silly logic/typing error. Then such error is welcome and it's fixed most times within seconds. But I appreciate I'm effectively forced to make the fix immediately and not allowed to be lazy now - at the cost of future headaches ;-)

Indeed, during normal development the existing behavior is desirable. Sometimes, when hunting a bug, you would add debug printing, or comment out a line, just to watch the effect of this change. You will not commit this change. In those case `go build --force` is more desirable. (Another feature you can add to --force mode, auto inference of pacakge imports. If go build detects usage of fmt, and a package named fmt exists - it'll automatically inject an import).

 

[Rémy Oudompheng]

if you comment out a block of code and a variable gets unused, maybe
it's because the declaration was in the wrong place. The declaration
should be commented along with the code.

Also, if you use fmt.Println for debugging, you can add a source file
that assigns it to a name (e.g. debugln) so that you can use it easily
without worrying about importing fmt.

Rémy

[Elazar Leibovich]

The thing is, I don't want this Println to stay in this file, I don't want those lines to stay commented. I want build to fail if they do. I just want them to be commented in the next few minutes, to test whether or not the file descriptor leaks from this function or not. The program is probably wrong, but I just need to find out if those lines are the source of the leak. (Or in the case of the Println statement, you want to see if there's a correlation to the weird crash your getting in special environment, and to the fact that this code path was ran. You never want those explorations to end out in a "real" build.

 

Rémy

[Lars Pensjö]

Regarding the discussion that you by accident failed to restore the source code because of several unrelated changes during debugging, the risk will increase because of the "used variable" enforcement". But I don't see that as a problem as I always use a version control system to carefully check what was changed.

On Friday, 23 March 2012 10:24:28 UTC+1, Jan Mercl wrote:

On Friday, March 23, 2012 10:06:18 AM UTC+1, Elazar Leibovich wrote:

_ = a // is shorter

And still I wouldn't recommend doing this. Just fix the error. Now, not later.

This technique is only used during the debug process. A common way is to comment out function calls, for example, and see how the behaviour of the program change. But if a variable is used in that function call only, then you need to also get rid of the compilation error from that variable. In worst, this will create more error messages from other unused variables. It is a waste of time to remove them all as a side effect.

[John Asmuth]

This is one of those things that seems foreign and weird to new Go programmers, but is really a non-issue once you start writing some code. Same with imports. You really need to just accept it, and then find out that your projects a much slower rate of code-rot than they normally do :)

[si guy]

Yes, my favorite use of unused imports is to help me clean out code. Now if only it would warn (or block compilation altogether) on unused struct members!

[Elazar Leibovich]

On Fri, Mar 23, 2012 at 4:07 PM, John Asmuth <jas...@gmail.com> wrote:

This is one of those things that seems foreign and weird to new Go programmers, but is really a non-issue once you start writing some code. Same with imports. You really need to just accept it, and then find out that your projects a much slower rate of code-rot than they normally do :)

My own experience was different. When I started with Go I didn't mind this lack of ability to ignore unused variables errors. However when starting to build a bit more complex apps, which suffered from complex bugs, I found out I need that in some workflow.

[roger peppe]

if i find myself adding and removing a particular package a lot,
i'll sometimes do something like:

var _ = log.Printf

which means i don't have to delete the import when i remove the last
use of that package.

[sdeg...@8thlight.com]

There's a better solution to this problem:

- Write many unit tests

- Have (approaching) 100% test coverage

- Use TDD for unit testing, meaning don't write extra code beyond what's needed to make the one failing test pass

- Test everything, leave no feature untested

- Don't forget to depend on interfaces when applicable, which makes testing certain things much easier

When using these tricks, you will probably find that you hardly need to debug (in the traditional sense) much at all.

-Steven

[Rémy Oudompheng]

I don't suffer from that even though I write complex apps. The only
case where I can find it annoying is in range loops where the range
variables that are actually used may vary. Otherwise, either a
variable is used only once and then it's declared near its usage, so
they are both commented at the same time, either it's used more than
once, and then there's no problem commenting blocks of code either.

Rémy.

[Liigo Zhuang]

+1
“Unused vars“ should be treated as warning, not error. Please stop forcing people do what they don't like. The compiler is a "tool", not "God", of programmers. Warning messages are enough for people to clean unused vars, if they want.

[jimmy frasche]

-1, if I don't do it now I never will

[andrey mirtchovski]

-1 the compiler is God, not some tool. if it don't compile it don't work.

[Kyle Lemons]

On Fri, Mar 23, 2012 at 7:16 PM, Liigo Zhuang <com....@gmail.com> wrote:

+1
“Unused vars“ should be treated as warning, not error. Please stop forcing people do what they don't like. The compiler is a "tool", not "God", of programmers. Warning messages are enough for people to clean unused vars, if they want.

If it's worth making a warning, it's worth making an error. 

[Erwin]

On 24 March 2012 17:47, Kyle Lemons <kev...@google.com> wrote:

On Fri, Mar 23, 2012 at 7:16 PM, Liigo Zhuang <com....@gmail.com> wrote:

+1
“Unused vars“ should be treated as warning, not error. Please stop forcing people do what they don't like. The compiler is a "tool", not "God", of programmers. Warning messages are enough for people to clean unused vars, if they want.

If it's worth making a warning, it's worth making an error.

The point is, i think, that such errors disrupt the flow of prototyping and debugging, while warnings do not. Once things have settled, one can fix the warnings. I guess everyone likes to see "0 errors, 0 warnings" in the end?

 

[Thomas Bushnell, BSG]

On Sat, Mar 24, 2012 at 11:07 AM, Erwin <snes...@gmail.com> wrote:

The point is, i think, that such errors disrupt the flow of prototyping and debugging, while warnings do not. Once things have settled, one can fix the warnings. I guess everyone likes to see "0 errors, 0 warnings" in the end?

Temporary prototypes of that sort have a disturbing way of becoming permanent.

 

[Elazar Leibovich]

I don't think this is a good idea. You might forget to remove this var _, and debugging code will end in production.

[Kees Varekamp]

I'm OK with the current setup, but it might help to convince others if anyone can give a really good real-life example of why allowing unused vars is such a bad thing? Or why even optionally allowing them is such a bad thing? And why is it so important to not allow unused variables, but at the same time it's fine to allow (private) unused functions or types?

[DisposaBoy]

On Saturday, March 24, 2012 10:51:07 PM UTC, Kees Varekamp wrote:

I'm OK with the current setup, but it might help to convince others if anyone can give a really good real-life example of why allowing unused vars is such a bad thing?

mVar := 123

...

nVar, err := f()

...

return mVar, err

 

Or why even optionally allowing them is such a bad thing?

I'm not against allowing it optionally but AFAIK the thing to keep in mind is that the compiler doesn't support warnings in the first place...

 

And why is it so important to not allow unused variables, but at the same time it's fine to allow (private) unused functions or types?

 

Are you trolling?

 

On Sunday, March 25, 2012 8:04:02 AM UTC+13, Elazar Leibovich wrote:

I don't think this is a good idea. You might forget to remove this var _, and debugging code will end in production.

[...]

[Kees Varekamp]

func mFunc(x int) {

...

}

func nFunc(x int) {

...

}

func main() {

return mFunc(123)

}

It's pretty much the same thing, isn't it?

[Hotei]

Not entirely.  You can pass the address of a function to another function that may or may not actually invoke it.  You wouldn't know until run-time if it was dead code or not.

[Elazar Leibovich]

On Fri, Mar 23, 2012 at 6:14 PM, <sdeg...@8thlight.com> wrote:

When using these tricks, you will probably find that you hardly need to debug (in the traditional sense) much at all.

I agree 100%. If you find yourself debugging too much - you're doing it wrong.

However, I find that sometimes despite the tests, and the coverage, I'm running into bugs from time to time. When I do run into bug, the are hard to catch, and occur in edge cases I didn't think of during the tests.

This workflow fits those cases. Doesn't happen every day, but when you need it - it's handy.

Maybe people more competent than I do never run into strange bugs, (I'm not sure this is true, since even Google chrome, which was developed with first class testing, have some strange bugs in the tracker), maybe only part of the community needs that.

But my point is, I don't see any damage with leaving this option behind a switch, and I see benefit to many people in the community.

[ron minnich]

On Sun, Mar 25, 2012 at 4:24 AM, Elazar Leibovich <ela...@gmail.com> wrote:

> But my point is, I don't see any damage with leaving this option behind a
> switch, and I see benefit to many people in the community.

The source is all there for you to try your idea out. I think the
discussion has run on longer than making the change would take.

?g are not gcc. It's a very compact compiler and it rewards inspection
... why not just give it a go, make your desired change, and let us
know how it works out?

I suspect you'll find it goes well in the early going, and it bites
you later. Every time I've seen this type of shortcut that's they way
it worked out.

thanks

ron

[Liigo Zhuang]

Almostly NO other compilers did this (refuse unused vars ). It's crazy.

[chris dollin]

On 26 March 2012 13:02, Liigo Zhuang <com....@gmail.com> wrote:
> Almostly NO other compilers did this (refuse unused vars ). It's crazy.

"Crazy" is a bit strong. "Sometimes inconvenient. occasionally
a pain" comes closer.

Unused variables and imports are so much more often a mistake
than not that it seems useful that they're rejected.

Apart from those times of flux when the code in the box may or may
not be dead, I don't want unused variables in my code. (I can't
remember why Go doesn't complain about unused nonexported
functions ...)

[Jan Mercl]

On Monday, March 26, 2012 2:02:05 PM UTC+2, Liigo Zhuang wrote:

Almostly NO other compilers did this (refuse unused vars ). It's crazy.

After coding in Go for few years I have to say it's a non problem and a pretty useful feature in the same time.

[Hotei]

It's far from crazy.  About 20% of the times I get the unused variables error there is a problem other than the unused variable itself.  Usually it is one variable masking another that I had NOT intended.  And this kind of error is very hard to find just by inspecting the code. With a "warning" it would have compiled just fine - and then not performed the correct calculation.  

I don't have any problem with a switch to turn off the default behavior - but I personally would never use it.  YMMV.

[Liigo Zhuang]

Error messages make you happy, and warning messages make me happy. An optional switcher of compiler will make all gophers happy. So I don't know why you guys oppose this so strongly. This is why I think someone maybe crazy.

[jimmy frasche]

It would make me unhappy. First in principle and then again when I
notice the first project that tells me you have to build it with that
optional switch.

[Steven Degutis]

+1

We don't work in isolated sandboxes, we work on real-world libs that affect other people, whether we realize it or not. Our poor code makes their lives harder. And sometimes this other-people is actually you, 3 years in the future. So let's make it as hard as we can for ourselves to write sloppy code, and let's try our best to prevent the same problems of the past from popping back up. One easy way to do this is to leave this feature alone, and consider it an error to have unused imports or variables.

-Steven

[Elazar Leibovich]

On Tue, Mar 27, 2012 at 2:41 AM, jimmy frasche <soapbo...@gmail.com> wrote:

It would make me unhappy. First in principle and then again when I
notice the first project that tells me you have to build it with that
optional switch.

No can do. go build will never build dependencies with this switch on. If you want to play in the go echosystem - your project must be built with go build. This switch is strictly for temporary usage during debugging.

Even the ones who wants this switch (like me) think that go build should treat them as errors, generally speaking.

[Lukasz]

The purpose of no warnings, I assume, is to avoid sloppy code. If there are a bunch of "var _ = foo" statements scattered about as workarounds to the no warning problem, then I'd say no warnings has failed miserably. If a programmer is not diligent enough to removing warnings when they are presented to him in a list at compile time then how is he supposed to be diligent enough to go through his code and remove all the empty assignments?

On Wednesday, 7 March 2012 22:58:45 UTC+11, emepyc wrote:

> Is there a flag that enables you to temporarily compile without this
> warning?

No, there is not such an option. It has been discussed several times in
this list.

You can use the blank identifier to avoid this issue:

To avoid unused imports:

var _ = fmt.Printf  // package fmt is now used

To avoid unused variables:

var _ = foo // foo is now used

These changes have little impact in the rest of the code

M;

[Jeremy Wall]

On Sat, Mar 24, 2012 at 1:07 PM, Erwin <snes...@gmail.com> wrote:
>
>
> On 24 March 2012 17:47, Kyle Lemons <kev...@google.com> wrote:
>>
>> On Fri, Mar 23, 2012 at 7:16 PM, Liigo Zhuang <com....@gmail.com> wrote:
>>>
>>> +1
>>> “Unused vars“ should be treated as warning, not error. Please stop
>>> forcing people do what they don't like. The compiler is a "tool", not "God",
>>> of programmers. Warning messages are enough for people to clean unused vars,
>>> if they want.

I can count on one hand the number of projects I've encountered that
actually compile clean with no warnings. I *really* like that Go is
opinionated in this way since I'm lazy and so are other people. Any
push in the right direction is great as far as I'm concerned.

[Aaron Bohannon]

On Thursday, May 24, 2012 12:33:32 AM UTC-4, Lukasz wrote:

If a programmer is not diligent enough to removing warnings when they are presented to him in a list at compile time then how is he supposed to be diligent enough to go through his code and remove all the empty assignments?

+1

If someone tells me I have to compile their code with "--disable-unused-variable-check", I will immediately know they are a crappy programmer and might not want to trust their code.  OTOH, if I search someone's source code and find some uses of "_", it may be hard for me to tell how legitimate that use is.  I don't think it's a good thing to encourage people to more cleverly hide their ineptitude.

Don't get me wrong, though...I am 100% in favor of fatal errors for unused variables as the default behavior of the compiler.  In fact, I don't think the Go compiler goes far enough.  Unused global variables/functions are no big deal, but why not check for unused function parameters?  That is no less a sign of a programmer error than unused local variables, right?

 - Aaron

[Elazar Leibovich]

On Sun, May 27, 2012 at 10:11 PM, Aaron Bohannon <aaro...@gmail.com> wrote:

but why not check for unused function parameters?  That is no less a sign of a programmer error than unused local variables, right?

You sometimes want that to implement an interface.

 

 - Aaron

[Steven Blenkinsop]

On Thursday, May 24, 2012, Lukasz wrote:
;

The purpose of no warnings, I assume, is to avoid sloppy code. If there are a bunch of "var _ = foo" statements scattered about as workarounds to the no warning problem, then I'd say no warnings has failed miserably. If a programmer is not diligent enough to removing warnings when they are presented to him in a list at compile time then how is he supposed to be diligent enough to go through his code and remove all the empty assignments?

Rust's approach is interesting because you prefix unused variables with an underscore. This combined with a compiler flag to turn on ignoring unused variables could serve to give you the combination of strong enforcement by default, and locality of exceptional cases. You could go a step further and disallow *using* variables prefixed with an underscore when the compiler flag is on, forcing people to keep their code properly factored if they want to use the feature.

[Jay Weisskopf]

END UNUSED VARIABLE PROHIBITION NOW!

Unused variables are generally a bad thing. I wouldn't want to be
caught in public with unused variables. I wouldn't want my parents to
know that I have unused variables. Sometimes unused variables are
indicative of larger problems. That said, they should NOT be illegal.
When I'm in the privacy of my own home, sometimes I just want to
create some damn variables and not use them! You holier-than-thou
puritans who want to ban unused variables should just mind your own
business! If you personally don't like unused variables, then use
them, but don't shove your preferences down my throat!

--------

In all seriousness, I have been playing with Go for a couple weeks now
and this "feature" has been one of my biggest sources of frustration.
I would never publish code that has unused variables or imports, but
treating it as a fatal error is really annoying (and borderline
insulting) when tinkering and prototyping.

Using _ to fake out the compiler seems like a very poor workaround to
me. I don't want to suppress unused detection altogether, I just want
to be WARNED.

- Jay

[Aaron Bohannon]

Fair point about methods.  It still would be nice to have a check for functions.

Another equally important check that the compiler could do but doesn't is checking for unused return values from methods and functions.  OCaml does that sort of check, probably a few other languages, too.  However, it seems like an _especially_ important check for a language whose error handling is based on error values returned by functions.

 - Aaron

[Andrew Gerrand]

It's perfectly reasonable to ignore a function's return values. In
this case, how would the compiler know the difference between a
mistake and a deliberate act?

Andrew

[minux]

And that is the reason gcc introduced __attribute__ ((__warn_unused_result__))

function annotation; but it's way too ugly for Go.

[Andrew Gerrand]

I agree. It needs way more underscores.

Andrew

[Uriel]

An alternative might be a convention using Go's named return values

It would be trivial to write a script (or extend go vet) to check that
any return value named 'err' is used.

[haini...@gmail.com]

when writing small stuff that I'm compiling while going through unfinished, I've found something like

unused := something(); _=unused

hacky and ugly and all those other bad things, but for temporarily disabling, it gets the job done.  Everyone tell me how much of a Go plebeian I am.

On Wednesday, March 7, 2012 6:32:19 AM UTC-5, Elazar Leibovich wrote:

I sometimes have a very strange error, which I can't understand its source.

One of my techniques for finding it, is isolate the problem to a very small case, by commenting out pieces of the code, and noticing which pieces of codes cause the problem.

Go really helps me with it due to the short compile run cycles, but it is very difficult to use this technique without leaving unused variables.

[Jan Mercl]

On Sat, Mar 15, 2014 at 5:19 PM, <haini...@gmail.com> wrote:
> when writing small stuff that I'm compiling while going through unfinished,
> I've found something like
>
> unused := something(); _=unused
>
> hacky and ugly and all those other bad things, but for temporarily
> disabling, it gets the job done.

In all_test.go

func use(...interface{}) {}

In debugged code

use(foo, bar, baz)

This will work only when all_test.go is used, ie. during go test. If
use(i, j, k) is accidentally left in the code after debugging, go
build or go install will remind you.

-j

[hareesh.ra...@blippar.com]

This is a terrible design on the part of Golang

http://catb.org/esr/writings/unix-koans/editor-wars.html

[andrey mirtchovski]

> This is a terrible design on the part of Golang

no, it isn't. it is a wonderful design on the part of Golang.

[hareesh.ra...@blippar.com]

Not everyone programs the way you do (or the way the folk who developed Go do). Top down programmers (maybe not all top down programmers, if you are one too, but most top down programmers) who see the whole before they see the components find it extremely annoying to debug code, when one is unable to comment out blocks of code (or create incomplete blocks of code) that form a logical module (imagine a knowledge graph), without also commenting out isolated lines of code in remote nodes outside the module. As a result Go does not work well with the mental model of programming for many top down thinkers, and a flag to disable unused import/variable errors is required to solve this problem.

[Andrew Gerrand]

Hareesh,

It's clear from this thread that some people feel the unused variable error is an annoyance. I think that Andrey, by contradicting you, was indirectly saying you didn't actually contribute anything to the discussion. Saying just "this is terrible design," is not productive, just as "it's a wonderful design" is not helpful either.

Thanks for providing a rationale for your statement in your subsequent message. While I can find ways to disagree with it (for instance, there are many other ways you can break code by commenting out large sections; unused variables are a small part of the issue), I think there is a more important, high level concern: the Go compiler, by design, does not emit warnings or provide options for how code is interpreted. Down that path lies the madness of gcc's seemingly infinite set of command-line flags. 

To make a practical suggestion: a more effective way of temporarily disabling code is to wrap it in an "if false {". This has the same effect as as comment, but doesn't cause "unused variable" such errors. It's also easy to later grep your code for "if false" to find such cases, while grepping for /* will likely return many false positives.

Cheers,

Andrew

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[simon place]

well, i guess i must work in the way where i would say i loose more time, to this, than i gain.

but i've noticed this;   http://play.golang.org/p/f1LRnF_yl9

ie no complaint at file root level, which apart from, for me, not being entirely consistent, does lead to a thought.

since their are two ways of declaring a variable;

"var x="  and "x:="   (the latter not allowed at root, which is also consistent with this.)

what about if the first way didn't trigger the complaint anywhere, so you could develop with that for the variables that might cause this, (use the latter when they couldn't ie within a block that couldn't sensible be disabled piecemeal.), and change to the former for distribution? or have a switch for just that type of declaration?

best of both worlds? and a use for the redundant declaration variants.

[Rich]

There are times when I've been compiling C / C++ code that I look at the warnings and such scrolling across the screen and wonder to myself, "how in the hell is this code going to even work?"  And these are well known Linux applications, not something I wrote myself.  While I've found this to be frustrating from time to time, I wouldn't want to change it. I didn't read every post in here so someone might have mentioned this, but think about variables that don't have the proper scope? How many times have we done something like this:

http://play.golang.org/p/4-Dzjl03tV

Its easy to find in a short function like this, but in a larger function it could be hard to find if you've given some flag to the compiler to ignore unused variables.

[simon place]

i think what you say applies to a fixed no-checking arrangement, not to a switch-able flag.

[xeng...@gmail.com]

So, 2019 year. Still no compiler flag. Sloooophers :)

среда, 7 марта 2012 г., 14:32:19 UTC+3 пользователь Elazar Leibovich написал:

[Ian Lance Taylor]

On Wed, Jan 9, 2019 at 1:46 PM <xeng...@gmail.com> wrote:
>
> So, 2019 year. Still no compiler flag. Sloooophers :)

This isn't a matter of being slow, it's an intentional decision.

Ian

[Glen Newton]

I use the "if false{..." extensively as described above.

[Rich]

Yes at times it's a pain, after programming for a while in Go you just get used to it, and I seldom run into an unused variable. Use Visual Studio Code, you'll get a red squiggly line and an error long before you ever try to compile the code. If you really want to keep the variable, variable=_ takes care of it. 

[Ekow]

It is a good kind of pain. 

This intentional construct forces you to only use what you need at the point where you actually need it. 

YAGNI.

Regards,

B Charles Jnr.

--

[robert engels]

I’m pretty sure that is rose colored glasses…

It is a pain, but at the same time, the lack of dynamic code modification is more of a pain, coupled with no private methods in file scope (because with those you could decompose the larger functions without polluting the namespace).

But in many ways, the inability to test/debug “interactively” does force you down the road to better design - but when you are debugging someone else’s code that’s a whole other issue...

Test cases mitigate the problem immensely.

[김용빈]

package main

func unused(x interface{}) {}

func main() {
    a := 1
    unused(a)
}

2012년 3월 7일 수요일 오후 8시 32분 19초 UTC+9, Elazar Leibovich 님의 말:

[Justin Israel]

On Thu, Jan 10, 2019 at 6:04 PM 김용빈 <kyb...@gmail.com> wrote:

package main

func unused(x interface{}) {}

func main() {
    a := 1
    unused(a)
}

The function isn't even required here. Assigning to underscore will prevent the error:

func main() {
    a := 1

    _ = a
}

 

2012년 3월 7일 수요일 오후 8시 32분 19초 UTC+9, Elazar Leibovich 님의 말:

I sometimes have a very strange error, which I can't understand its source.

One of my techniques for finding it, is isolate the problem to a very small case, by commenting out pieces of the code, and noticing which pieces of codes cause the problem.

Go really helps me with it due to the short compile run cycles, but it is very difficult to use this technique without leaving unused variables.

Is there a flag that enables you to temporarily compile without this warning?

--

[Jan Mercl]

On Thu, Jan 10, 2019 at 6:30 AM Justin Israel <justin...@gmail.com> wrote:

On Thu, Jan 10, 2019 at 6:04 PM 김용빈 <kyb...@gmail.com> wrote:

package main

func unused(x interface{}) {}

func main() {
    a := 1
    unused(a)
}

The function isn't even required here. Assigning to underscore will prevent the error:

func main() {
    a := 1

    _ = a
}

 Both versions above have the same problem - it's possible to forgot the bypass hack in production code.

For many years I'm using

        func use(...interface{}) {}

but defined in tests, for example in all_test.go. This enables easy disabling of the 'unused variable' error during development/debugging, but the code does not otherwise compile until the 'use(foo, bar') hack is removed or commented out.

--

-j