Why does Go allow compilation of unused function parameters?

Question

One of the most noteworthy aspects of Go when exiting C is that the compiler will not create your program if it has an unused variable. So, why is it creating a program if a function has an unused parameter?

func main() { print(computron(3, -3)); } func computron(param_a int, param_b int) int { return 3 * param_a; } 

Answer 1

There is no official reason, but the reason superimposed on the golanuts:

Unused variables are always a programming error, while writing a function that does not use all of its arguments.

You can leave these arguments unnamed (using _), but then it can be confused with features like

func foo (_ string, _ int) // what should this do?

Names, even if not used, provide important documentation.

Andrew

https://groups.google.com/forum/#!topic/golang-nuts/q09H61oxwWw

Sometimes using unused parameters is important for satisfying the interfaces, one example might be a function that works on a weighted graph. If you want to implement a graph with the same cost along all edges, it is useless to consider the nodes:

 func (graph *MyGraph) Distance(node1,node2 Node) int { return 1 } 

As this thread notes, there is a valid argument that allows only parameters with the name _ to be allowed if they are not used (for example, Distance(_,_ Node) ), but at this point it is too late due to Go 1 future compatibility guarantee . As also mentioned, a possible objection to this is that parameters, even if they are not used, can implicitly provide documentation.

In short: there is no specific concrete answer, except that they simply made an ultimately arbitrary (but still educated) determination that unused parameters are more important and useful than unused local variables and imports. If once there was a strong design reason, it is not documented anywhere.

Answer 2

The main reason is the possibility of implementing interfaces that define specific methods with specific parameters, even if you do not use them all in your implementation. This is described in detail in @Jsor's answer.

Another good reason is that unused (local) variables are often the result of an error or the use of a language function (for example, using a short declaration of the variable := in a block, inadvertently obscuring the "external" variable), while unused function parameters never (or very rarely) are not the result of an error.

Another reason may be to ensure advanced compatibility. If you release the library, you cannot change or expand the list of parameters without breaking backward compatibility (and there is no function overload in Go: if you want 2 options with different parameters, their names must also be different).

You can provide an exported function or method and add additional - not yet used - or additional parameters (for example, hints) to it in the spirit that you can use in a future version / release of your library.

Doing this very early will give you the advantage that other users using your library should not change anything in their code.

Let's look at an example:

You want to create a formatting function:

 // FormatSize formats the specified size (bytes) to a string. func FormatSize(size int) string { return fmt.Sprintf("%d bytes", size) } 

You can also add an additional parameter:

 // FormatSize formats the specified size (bytes) to a string. // flags can be used to alter the output format. Not yet used. func FormatSize(size int, flags int) string { return fmt.Sprintf("%d bytes", size) } 

Then you can improve your library and your FormatSize() function to support the following formatting flags:

 const ( FlagAutoUnit = 1 << iota // Automatically format as KB, MB, GB etc. FlagSI // Use SI conversion (1000 instead of 1024) FlagGroupDecimals // Format number using decimal grouping ) // FormatSize formats the specified size (bytes) to a string. // flags can be used to alter the output format. func FormatSize(size int, flags int) string { var s string // Check flags and format accordingly // ... return s }