proposal: spec: make unused variables not an error

[dancojocaru2000]

Seeing as Go is a tiny bit more open minded, going from "GOPATH is the best and only way and it will always be this way absolutely totally" to soon removing it entirely, I'm taking my chances.

A lot of people find no value in this error. Furthermore, many people find it as a hinderance, a bad part of the compiler and the language.

And since the way to get rid of it is simply to _ = variable, which changes nothing in the behavior of the compiled program, this error helps solve nothing related to the running of the program. It's just an annoying reminder of "you forgot to explicitly ignore the variable before you debug and then make actual use of it later anyway like it always happens".

Therefore, according to the FAQ's reasoning: "And if it's not worth fixing, it's not worth mentioning.", Go should stop mentioning this.

---

And just in case, to address the potential question of "But what about people who find this useful?".

Other languages deal with this easily using linters. That way, people who find an use in this error can keep it, while not impeding both the productivity and joy of many others.

[ianlancetaylor]

I think this is effectively a dup of #513, #958, #1085.

[DeedleFake]

A lot of people find no value in this error. Furthermore, many people find it as a hinderance, a bad part of the compiler and the language.

I'd like some references, if possible. It can be annoying sometimes, sure, but I quite like this error, actually.

And since the way to get rid of it is simply to _ = variable

This is not the way to get rid of it. The way to get rid of it is to get rid of the variable that you're not using anyways. If you're just debugging and need something removed temporarily, just comment the variable out. If you're not using it anyways, it should generally be pretty easy to do so. The only time I've found it annoying is when it's a variable declared in a condition or it's part of a multi-return value declaration, but it's still only a minor annoyance. Personally, I think that the benefit, namely making sure that you don't have pointless local variables laying around, cluttering up your code, outweighs those annoyances.

[dancojocaru2000]

Only somewhat. Rather than just complaining about the error, I'm pointing out that by the very reasoning in #1085 it shouldn't exist.

Many people find this a matter that shouldn't be fixed. Therefore, Go shouldn't complain about it.

[dancojocaru2000]

I'd like some references, if possible.

It will be very time consuming to go on the web and look for every individual finding this annoying. Someone on a Reddit post even thought it was a joke and actually looked up Go to see if this is an actual error.

Regardless, since there were three other issues mentioned as potential duplicates and an FAQ section dedicated to this, I will say this is enough to show this this is more than a couple of people who find this a bad part of the langauge.

It can be annoying sometimes, sure, but I quite like this error, actually.

And I dislike the error, so we're equal. :P

Jokes aside, I opened this issue in the hopes that Go moved on from the days of "GOPATH is best and we'll ignore all the negative feedback even if only 10 people will actually like our way". I mean no offense if you're one of the people who finds this useful, but is this good enough when it annoys or even hinders many others?

The way to get rid of it is to get rid of the variable that you're not using anyways.

But what if I'm using it, just not in the way Go expects me to? For example, a common thing I do in other langauges is to declare a variable for the result of a function and then debug until there to see what the function will return. The use of that variable is just to see its value in the debugger, yet Go can't know that it's useful to me.

Or maybe its use is planning ahead, making an idea of what the code will look like. Even if I don't use that variable yet, maybe it will help me to have it there, with the function that creates it called already with the right parameters, but the part that uses it not done yet. If I'm gonna uncomment it later, why comment?

Personally, I think that the benefit, namely making sure that you don't have pointless local variables laying around, cluttering up your code, outweighs those annoyances.

The benefit is a couple less bytes of code. At most a slight visual disturbance in a little piece of the code.

The downside ranges depending on people from mild annoyance to workflow disruption, especially people used to other langauges.

To me, the benefit is insignificant and the downside is quite big.

---

And, finally, once again, if it benefits you, that's great! Just like the FAQ proposed a tool as a potential (but imo bad) solution for the unused import error, I propose a tool - a linter - that can be used to give you this error back if it is removed from the compiler.

All I'm proposing is that this benefit for some should be kept, but the hinderance to others should be removed.

[mvdan]

You say this is a big downside for a lot of people, but I can't see any evidence for that statement. For example, if it truly were one of Go's biggest problems, or one that most newcomers struggled with, I would imagine it would show up in developer surveys like https://blog.golang.org/survey2019-results.

Personally, I do see some newcomers surprised by the Go compiler's stance on errors and warnings, but everyone I've worked with gets used to it after a few weeks. There are clear benefits to having this be a compiler error, because it means the check is widespread and hard to ignore. The only downside I see is getting used to it, or the slight annoyance while running unfinished code. But again, I don't see any proof that this is actually a large problem for a lot of Go users.

[beoran]

This error has save me many times in cases where I thought I was using a variable, but wasn't. It should stay as it is very useful for this case.

[dancojocaru2000]

@beoran As I said, this will be equally as useful as a linter, who would also be able to point it out to you.

It just wouldn't bother those who find this one of the pain points of using Go anymore.

[dancojocaru2000]

@mvdan Those developer surveys are not entirely representative of everybody. In particular, they're not representative of people who wanted to learn Go, got screamed at by the compiler and were confused until they found out that you can't have else on a new line and, out of frustration, gave up on learning Go. (Speaking from experience from the first time I tried Go, back when Go modules didn't exist).

At that beginner level, the advantages of Go might not be too clear, and, when faced with an overly restrictive compiler, C++/Python/Node.js do just fine, why bother fighting with a mean compiler and a confusing language?

And since those people generally don't stick around in the Go community to express their disappointment, they're not really heard. They just silently come and go.

Since I didn't hear of that survey until you linked it, it's safe to say that only a certain category of people are represented by it.

I'm not saying that this only affects beginners (on that Reddit post I linked there are a couple of Go users who point out that this is one of the annoyances of using the language). All I'm saying is that quoting such a survey where in all likelihood there's mainly people who like most or all of Go answering isn't exactly the perfect counter argument. "100% of people who like it say they like it"-ish.

[mvdan]

this will be equally as useful as a linter, who would also be able to point it out to you.

A linter people have to enable will be used by fewer people.

not representative of people who wanted to learn Go

I'm happy to hear about any other way to objectively measure the impact of this compiler error. Personal experience is not really representative. Similarly, online threads tend to attract vocal or unhappy people, so they aren't a good way to get an overall picture.

[davecheney]

Those developer surveys are not entirely representative of everybody.

respectfully this is a mutated version of the “no true Scotsman” argument. Four yearly surveys have not shown that unused variables are a significant cause of complaint. Ignoring this inconvenient fact does not validate your arguments.

I understand that this decision, which was made in the earliest days of go’s development, is not your personal preference, but please understand that of all the things which are unlikely to change in go, this is at the top of the list.

[dancojocaru2000]

A linter people have to enable will be used by fewer people.

That's the point? Since not everybody appreciates or wants the error, the logical conclusion is that there will be fewer people.

I'm happy to hear about any other way to objectively measure the impact of this compiler error.

"Does it need an FAQ entry addressing the issue?" would be one. Since enough people complained that it warranted a detailed FAQ entry, and complaints come in even after that, would that not be a good enough measure?

Similarly, online threads tend to attract vocal or unhappy people

So only people happy with the situation should be listened to? Back to "100% of people who like it said they like it"?

so they aren't a good way to get an overall picture.

Not only listening to them, no, of course. But does saying "those opinions aren't valid" not reduce the quality of the overall picture?

I understand that this decision, which was made in the earliest days of go’s development

Wasn't "write all code in GOPATH" the same?

but please understand that of all the things which are unlikely to change in go, this is at the top of the list

Back when Go modules weren't a thing yet, I was figuratively screamed at when I complained about GOPATH being inconvenient. It was the best way to go and it was never gonna change. Now it's soon entirely gone.

Recall that this was my reasoning for bringing this issue up in the first place. Langauges change as they evolve. Maybe if this decision was made early in development, it might mean that it was made without having the community of today to consult with and it might have been a bad decision?

---

Of course, it's totally a possibility that only like 1% of Go users dislike this. Maybe for people who got used to it it's just annoying on the spot but it's not annoying enough to remember to write it in the survey. I may be a minority and in that case fine, not everybody must fully enjoy the language.

At the same time, quoting just the survey and ignoring what people of online forums say feels a bit like sticking the head in the sand. Which can be acceptable. After all, the core team decides what the language should be. People who like it will use it, people who don't will use something else. C'est la vie. There will appear an issue about it every once in a while, respond with link to FAQ, marked as duplicate, closed, bye.

I just wanted to try to make a case.

[dancojocaru2000]

Oh, also, about that survey and related to "other way to objectively measure the impact of this compiler error". I see it's a survey of Go users. Maybe a survey of people who tried Go but abandoned it would also be helpful? "What made you leave?"

[beoran]

UseLet me quote purplepharoh from that Reddit thread:

"The thing about GO is that it enforces good practices with compiler errors. For example this could be a warning but most people ignore warnings and often don't fix them, good practice is to remove (or use) unused variables so GO enforces this."

This is an essential feature of Go which ensures consistency and minimum code quality. Code is read more often than it is written and unused variables left over from development are a hindrance to reading. An unused variable definitely is bad practice since it indicates unfinished code or messy code, or worse, a shadowed variable. The latter often happens with err error variables.

For your use case of return values in the debugger, just declare your function with variables for the return, e. g. func Square(in int) (res int).

For planning code, your functions are too complex if you want to add unused variables in there for planning purposes. Besides, in other languages, they have the tendency to stick around when they end up being unneeded after all, or become redundant.

I had similar feelings about Go 10 years ago when I learned Go, but I changed my mind after a few months. While the Go approach of enforcing good practice takes some getting used to, especially when coming from a different language, once you get the hang of it, you'll reap the benefits.