In Go, is there any way to compare two non-nil function pointers to test for equality? My standard of equality is pointer equality. If not, is there any particular reason why pointer equality is not allowed?
As of now, if I attempt to do this in the straight-forward way:
package main
import "fmt"
func SomeFun() {
}
func main() {
fmt.Println(SomeFun == SomeFun)
}
I get
./func-pointers.go:12: invalid operation: SomeFun == SomeFun (func can only be compared to nil)
It is my understanding that this behavior was introduced recently.
I've found an answer using the reflect package; however Atom suggests below that this actually produces undefined behavior. See Atom's post for more info and a possible alternative solution.
package main
import "fmt"
import "reflect"
func SomeFun() { }
func AnotherFun() { }
func main() {
sf1 := reflect.ValueOf(SomeFun)
sf2 := reflect.ValueOf(SomeFun)
fmt.Println(sf1.Pointer() == sf2.Pointer())
af1 := reflect.ValueOf(AnotherFun)
fmt.Println(sf1.Pointer() == af1.Pointer())
}
Outputs:
true
false
The workaround depends on the situtation. I had to change a couple of places where I was comparing functions. In once case I just did something different so I wouldn't need to compare them any more. In another case I used a struct to associate functions with comparable strings, something like,
I only had a couple of functions I needed to compare so it was simplest to keep a slice of these structs and scan the slice as needed, comparing the name field and dispatching fval. If you have very many you might use a map instead. If your functions have different signatures you could use interfaces, and so on.
Note that there is a difference between equality and identity. The operators
==
and!=
in Go1 are comparing the values for equivalence (except when comparing channels), not for identity. Because these operators are trying not to mix equality and identity, Go1 is more consistent than pre-Go1 in this respect.Function equality is different from function identity.
One reason for not allowing
==
and!=
on function types is performance. For example, the following closure is not using any variables from its environment:Disallowing comparisons of functions enables the compiler to generate a single implementation for the closure, instead of requiring the run-time to create a new closure (at run-time). So, from performance viewpoint the decision to disallow function comparisons was a good decision.
In relation to using the
reflect
package to determine function identity, a code likerelies on undefined behavior. There are no guarantees as to what the program will print. The compiler may decide that it will merge
SomeFun
andAnotherFun
into a single implementation, in which case the 2nd print statement would printtrue
. In fact, there is absolutely no guarantee that the 1st print statement will printtrue
(it may, under some other Go1 compiler and run-time, printfalse
).A correct answer to your original question is: