Why Can't I Use Shared Methods with Go Generics' Union Constraints?

Union Constraints in Go Generics: Unresolved Limitations

In the realm of Go generics, type union constraints have sparked some confusion. When attempting to use a common method for types within a union constraint, the compiler throws an error, leaving developers scratching their heads.

Consider the following code:

type A struct {}
type B struct {}
type AB interface { *A | *B }

func (a *A) some() bool { return true }
func (b *B) some() bool { return false }
func some[T AB](x T) bool { return x.some() } // Compilation error

The compiler complains that x.some is undefined, even though both *A and *B implement the some method. This begs the question: why define a union constraint at all if shared methods cannot be utilized?

The workaround, as suggested by the Go tracker, is to add the method to the interface constraint:

type AB interface { *A | *B ; some() bool }
func some[T AB](x T) bool { return x.some() } // Compiles

However, this is an imperfect solution. Go's type union constraints should allow for shared methods without requiring an explicit interface declaration. Unfortunately, this is a limitation of Go 1.18, documented in the release notes:

The Go compiler currently only supports calling a method m on a value x of type parameter type P if m is explicitly declared by P's constraint interface.

This limitation is expected to be addressed in Go 1.19. Until then, developers must rely on the workaround or define unified interfaces for shared methods.

The above is the detailed content of Why Can't I Use Shared Methods with Go Generics' Union Constraints?. For more information, please follow other related articles on the PHP Chinese website!