在 go (1.18) 中对泛型进行多态实现的最佳方法是什么？

Question

我想创建一个 Vector 类型，它在其内部数据上是通用的，但在给定输入类型的情况下，方法的实现方式可能有所不同。

type SupportedType interface {

         ~int64 | ~uint64 |  ~float64 | string | bool | time.Time

}

type Vec[T SupportedType] struct {

    data []T

}

我想根据类型在函数上添加不同的实现。例如：

func (vec Vec[T]) Sort() {

    ...

}

在大多数通用类型<中都可以正常工作。但是，如果T -> time.Time我想使用该Before方法，T --> bool那么我希望所有假值都在真值之前。

我对如何实现这一点有一些想法，但在新的仿制药世界中，什么会被认为是“惯用的”？我的应用程序对性能敏感。

将类型联合与所有具有相同功能的类型一起使用是行不通的 ( https://play.golang.com/p/QWE-XteWpjL )。

在类型特定的结构中嵌入容器确实有效（https://play.golang.com/p/j0AR48Mto-a），但需要使用接口，这意味着示例函数中的LessandVal不能内联。如果类型联合中的子集之间没有清晰的描述，它也可能无法很好地工作。

Answer 1

顺便说一句，已经有一个用于排序的库https://pkg.go.dev/golang.org/x/exp/slices#Sort1. 您可以使用泛型创建接口，然后为其键入断言。例子：type Lesser[T SupportedType] interface {&nbsp; &nbsp; Less(T) bool}type Vec[T SupportedType] []Tfunc (vec Vec[T]) Less(a, b int) bool {&nbsp; &nbsp; return any(vec[a]).(Lesser[T]).Less(vec[b])}func main() {&nbsp; &nbsp; vs := Vec[String]([]String{"a", "b", "c", "d", "e"})&nbsp; &nbsp; vb := Vec[Bool]([]Bool{false, true})&nbsp; &nbsp; fmt.Println(vs.Less(3, 1))&nbsp; &nbsp; fmt.Println(vb.Less(0, 1))}游乐场 12.可以保存Vec上的类型。例子：type Lesser[T SupportedType] interface {&nbsp; &nbsp; Less(T) bool}type Vec[T SupportedType, L Lesser[T]] []Tfunc (vec Vec[T, L]) Less(a, b int) bool {&nbsp; &nbsp; return any(vec[a]).(L).Less(vec[b])}func main() {&nbsp; &nbsp; vs := Vec[String, String]([]String{"a", "b", "c", "d", "e"})&nbsp; &nbsp; fmt.Println(vs.Less(3, 1))}游乐场 23.嵌套类型约束谢谢@blackgreen例子 ：type SupportedType interface {&nbsp; &nbsp; Int8 | Time | Bool | String}type Lesser[T SupportedType] interface {&nbsp; &nbsp; Less(T) bool}type Vec[T interface {&nbsp; &nbsp; SupportedType&nbsp; &nbsp; Lesser[T]}] []Tfunc (vec Vec[T]) Less(a, b int) bool {&nbsp; &nbsp; return vec[a].Less(vec[b])}func main() {&nbsp; &nbsp; vs := Vec[String]([]String{"a", "b", "c", "d", "e"})&nbsp; &nbsp; fmt.Println(vs.Less(3, 1))}游乐场 3基准：benchmark 1 : 28093368&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 36.52 ns/op&nbsp; &nbsp; &nbsp; &nbsp;16 B/op&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 1 allocs/opbenchmark 2 : 164784321&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 7.231 ns/op&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 B/op&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 0 allocs/opbenchmark 3 : 212480662&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 5.733 ns/op&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 B/op&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 0 allocs/opEmbedding a container inside type specific structs:benchmark 4 : 211429621&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 5.720 ns/op&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0 B/op&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 0 allocs/op哪一个最适合您取决于您。但 IMO 3 号是最好的。

Answer 2

就我个人而言，我认为最好不要在联合中包含许多彼此无关的类型，因为它们不会共享许多通用操作，并且您最终会编写特定于类型的代码。那么使用泛型的意义何在……？无论如何，可能的策略取决于SupportedType约束类型集中包含的内容，以及您希望对这些内容执行的操作：只有确切的类型，没有方法使用类型开关T并运行任何对具体类型有意义的操作。当方法实现仅使用 type 的一个值时，这种方法效果最好T，因为您可以直接使用 switch guard ( v := any(vec[a]).(type)) 中的变量。当您T在 switch guard 中的值旁边有更多值时，它就不再漂亮了，因为您必须单独转换和断言所有这些值：func (vec Vec[T]) Less(a, b int) bool {&nbsp; &nbsp; switch v := any(vec[a]).(type) {&nbsp; &nbsp; case int64:&nbsp; &nbsp; &nbsp; &nbsp; return v < any(vec[b]).(int64)&nbsp; &nbsp; case time.Time:&nbsp; &nbsp; &nbsp; &nbsp; return v.Before(any(vec[b]).(time.Time))&nbsp; &nbsp; // more cases...&nbsp; &nbsp; }&nbsp; &nbsp; return false}用方法参数化包含方法的接口并将其约束T为支持的类型。然后将Vector类型参数约束为两者。这个的优点是确保Vector不能使用您忘记实现Less(T) bool的类型实例化并摆脱类型断言，否则可能会在运行时出现恐慌。type Lesser[T SupportedType] interface {&nbsp; &nbsp; Less(T) bool}type Vec[T interface { SupportedType; Lesser[T] }] []Tfunc (vec Vec[T]) Less(a, b int) bool {&nbsp; &nbsp; return vec[a].Less(vec[b])}使用方法和预先声明的类型不可能的。考虑以下：type SupportedTypes interface {&nbsp; &nbsp; // exact predeclared types&nbsp; &nbsp; int | string}type Lesser[T SupportedTypes] interface {&nbsp; &nbsp; Less(T) bool}约束Lesser有一个空类型集，因为既int不能也string不能有方法。所以在这里你回到了“精确类型和无方法”的情况。具有近似类型 ( ~T)将上面的约束条件改成近似类型：type SupportedTypes interface {&nbsp; &nbsp; // approximate types&nbsp; &nbsp; ~int | ~string}type Lesser[T SupportedTypes] interface {&nbsp; &nbsp; Less(T) bool}类型开关不是一个选项，因为case ~int:它不合法。约束上存在的方法会阻止您使用预先声明的类型进行实例化：Vector[MyInt8]{} // ok when MyInt8 implements LesserVector[int8]&nbsp; &nbsp; &nbsp;// doesn't compile, int8 can't implement Lesser所以我看到的选项是：强制客户端代码使用定义的类型，在许多情况下这可能很好将约束的范围缩小到支持相同操作的类型反射（用于查看性能损失是否对您来说太多的基准），但反射实际上无法找到基础类型，因此您只能使用reflect.Kindor进行一些黑客攻击CanConvert。当/如果该提案通过时，这可能会改善并可能胜过其他选项。