As Rob Pike mentions in this thread
Is it possible to express "any map", "any array" or "any slice" in a Go type switch?
No. The static types must be exact.
The empty interface is really a type, not a wildcard.
You only could iterate over a list of a specific type, like an interface with known functions.
You can see an example with "Can we write a generic array/slice deduplication in go?"
Even using reflection, to pass a slice as an interface{}
would be, as this thread shows, error-prone (see this example).
Update Nov. 2021, 7 years later: CL 363434, for Go 1.18 (Q1 2022) actually introduces functions useful with slices of any type, using generics.
// Package slices defines various functions useful with slices of any type.
// Unless otherwise specified, these functions all apply to the elements
// of a slice at index 0 <= i < len(s).
package slices
import "golang.org/x/exp/constraints"
// Equal reports whether two slices are equal: the same length and all
// elements equal. If the lengths are different, Equal returns false.
// Otherwise, the elements are compared in index order, and the
// comparison stops at the first unequal pair.
// Floating point NaNs are not considered equal.
func Equal[T comparable](s1, s2 []T) bool {
if len(s1) != len(s2) {
return false
}
for i, v1 := range s1 {
v2 := s2[i]
if v1 != v2 {
return false
}
}
return true
}
Note that issue 50792 and CL 382834 show that:
We left constraints
behind in the standard library because we believed it was fundamental to using generics, but in practice that hasn't proven to be the case.
In particular, most code uses any
or comparable
.
If those are the only common constraints, maybe we don't need the package.
Or if constraints.Ordered
is the only other commonly used constraint, maybe that should be a predeclared identifier next to any
and comparable
.
Hence import "golang.org/x/exp/constraints"
instead of import "constraints"
.