proposal: spec: disallow unused const in func body

[zimmski]

In retrospective to the discussion on golang-nuts https://groups.google.com/forum/#!topic/golang-nuts/F1KskeC2IdU I want to propose (I guess this should get the GO2 label) that it should be illegal to declare a constant inside a function body if the constant is never used.

E.g. this example https://play.golang.org/p/JG9dSa_VKg with an unused constant inside a function body should have a compile error "x declared and not used" like https://play.golang.org/p/KLzHVO5L7q has for an unused variable.

Such compile errors do already exist as is shown for variables, as well as for imports and labels. However, constants are at currently the exception. Even though there is an accepted explanation to why such usages are forbidden: "... Go refuses to compile programs with unused variables or imports, trading short-term convenience for long-term build speed and program clarity." [https://golang.org/doc/faq#unused_variables_and_imports]

[bradfitz]

I'll flag this for consideration for any hypothetical Go2. It's not a guarantee it will be accepted, though.

[minux]

I don't think unused variables are prohibited in the spec, so unused constants shouldn't be made illegal in the spec.

[zimmski]

https://golang.org/ref/spec#Variable_declarations states Implementation restriction: A compiler may make it illegal to declare a variable inside a function body if the variable is never used.. I would like to add the same restriction for constants.

[griesemer]

I am against this, at least as long as there isn't a more compelling argument.

As @minux already pointed out, even for variables, it's an implementation restriction (though I admit that effectively that's the same as a spec rule). But as @ianlancetaylor has said in the golang-nuts discussion, the reason for the restriction is that a variable that has been assigned to but that's not used often indicates a problem in the code (and a variable that's declared but not used counts as 'assigned to' because it's initialized to its zero value). The same is true for labels. An unused constant really doesn't pose a problem.

Thus, the other rules are really motivated by problems encountered in praxis, which is not the case here. We'd rather have fewer rules, after all, not more.

[robpike]

The effect of an unused constant is equivalent to that of a comment, and may even serve as a comment. I too think this should not be changed.

[pwaller]

One might want to define an "Enum-style" block of consts with some which happen to be unused now, but may be used later. Sure, you could comment out the consts you're not using right now, but that may be inconvenient if the block is large.

Your proposal is restricted to changing the behaviour to that consts defined in functions (and not at the package level). That would make consts in functions special compared with package consts, which would be surprising to anyone who didn't happen to know that fact. Imagine the poor user at the point of failure: "Why is the compiler complaining in this case? When it doesn't complain in that case?! This is a compiler bug!".

[ianlancetaylor]

@pwaller In fairness, a similar distinction between function scope and package scope already exists. The compiler accepts unused variables at package scopes and rejects them in function scope (see the "implementation restriction" in https://golang.org/ref/spec#Variable_declarations).

[ianlancetaylor]

Thanks, but, based on the comments by @griesemer and @robpike, we are not going to do this.