Why Does Golang Allow Compilation of Unused Functions?

Question

Private/unexported functions not used could be detected. Why the compiler doesn't complain like it does for unused variables?

Edit: The question also applies to unused private types/interfaces too.

Because they can be removed without side effects (except for `init`, which always runs). Variables less so because their instantiation may have side effects. Also, unused variables on package level are allowed. — thwd, Sep 14 '15 at 12:38
I thought that they do that to keep the code clean too not only to avoid side effects(i.e. allocations) — Anthony Hunt, Sep 14 '15 at 13:30
Unused types (interfaces, structs) also aren't an error. I think the only real answer is that while a programmer can reasonably avoid unused local variables and imports, it would be too difficult to build anything if you could never compile an unused helper function or type. — Linear, Sep 14 '15 at 13:35
I also wondered about why unused function parameters aren't flagged as errors, but I figured that obviously must be so that a type can satisfy an interface even though it doesn't need all the parameters of a certain method. — rob74, Sep 14 '15 at 13:47
@rob74 I actually wrote an answer about that one: http://stackoverflow.com/questions/22549228/why-does-golang-allow-compilation-of-unused-function-parameters/22549439#22549439 — Linear, Sep 14 '15 at 13:55
Calling one of the functions with reflection would also cause an issue for this matter. If you would let the compiler be strict on this you wouldn't be able to compile reasonable "valid" code that calls a function by reflection. — , Sep 15 '15 at 10:54
@ErwinRenkema I'm not sure I understand this. Is it possible to call arbitrary functions though reflection? — Anthony Hunt, Sep 15 '15 at 16:00
right... methods, though I think it's doable to find that with static analysis. — Anthony Hunt, Sep 15 '15 at 18:19
@Jsor It doesn't make sense to me. Why would it be too difficult to compile something that you don't use anyway? — Anthony Hunt, Oct 03 '15 at 13:46
@AnthonyHunt too difficult for the **programmer** to build something. — Linear, Oct 03 '15 at 21:52
Does this answer your question? [Why can we have unused functions but we can't have unused variables?](https://stackoverflow.com/questions/33753454/why-can-we-have-unused-functions-but-we-cant-have-unused-variables) — Erwin Bolwidt, Feb 23 '23 at 00:54

score 4 · Answer 1 · edited May 23 '17 at 11:46

I believe this is a combination of scope and the default interface {}.

This is the same reason that you can declare a variable at the package level that is unused and the code will build just fine.

This snippet is perfectly valid go code:

package main
import (
  "fmt"
  "time"
)

var (
  testVar = "sup"
)

func main() {
  start := time.Now()

  fmt.Println("This sure was a test")

  //Mon Jan 2 15:04:05 -0700 MST 2006
  fmt.Println("Finished!\nTimeElapsed:", time.Since(start))
}

Even though the variable testVar is never used.

There are several related questions here, and I think they all have the same general answer.

Why are unused variables not allowed?
Why are unused function parameters allowed if unused variables are not?
Why are unused functions/structs allowed?

...

The general answer is that unused variables in the scope of a function are ALWAYS either a waste of compiler time, or a legitimate error - so they are strictly not allowed.

However, unused function parameters, as well as private structs and functions, may satisfy an interface. At the very least they ALL satisfy the default interface {}. And as such, they are not at all guaranteed to be errors..

There doesn't appear to be any official documentation outlining the reasoning behind this particular corner of the golang philosophy, but as pointed out in the answer to a similar question you might have better luck finding answers and asking questions on the golang-nuts forum.

Hope this helps!

Why Does Golang Allow Compilation of Unused Functions?

1 Answers1

Linked