Go 泛型

2021.12.14 日，Go 官方正式发布了支持泛型的 Go 1.18 beta1 版本，这是 Go 语言自 2007 年诞生以来，最重大的功能变革。

泛型带来语言表达能力进一步提升，在整个设计过程中也是动态和静态的一次次 Trade Off，整个泛型主要有三个核心概念：

• Type parameters for functions and types
• Type sets defined by interfaces
• Type inference

Type Parameters

Go 语法规定在中括号中可以定义一组类型参数，比如 [T constraint, U constraint] 定义了 T、U 两个类型参数，constraint 是对参数的类型限制。

Constraint

对参数的约束可以是 Go 中的各种基本类型，也就是我们在不使用泛型时写的那些，比如：

• int
• int8
• int16
• int32
• int64
• uint
• ...
• uintptr
• float32
• float64
• string

有两个特殊的：

• any 代表任何类型
• comparable 代表所有可比较的类型 (booleans, numbers, strings, pointers, channels, arrays of comparable types, structs whose fields are all comparable types).

Generic Functions

定义好的类型参数可以用在函数上，这样一个函数就能支持多种不同的类型。

在不支持泛型时，比如 math 包中的 Min 函数只支持 float64 的大小比较（官方实现一个最复杂的），如果想支持其他类型，只能实现多个函数 MinInt、MinComplex 或使用 interface{} 加 reflect 实现。

使用泛型就很简单了：

func Min[T int | float64](x, y T) T {
	if x < y {
		return x
	}
	return y
}

定义类型参数 T，约束它的类型为 int 或 float64，此时这个函数在这两张类型的情况下都可以使用：

Min[int](1, 2)
Min[float64](1.5, 2.5)

Instantiation（实例化）

上面在调用 Min 函数时增加了中括号 [int]，这其实是在对泛型函数实例化，在编译期将泛型函数里的类型参数 T 替换为 int。

泛型函数的实例化主要做 2 个事情：

1. 检查实际参数是否满足参数定义的类型限制
2. 泛型参数替换为实际参数，比如 T 替换为 int

任何一步失败了，那泛型函数的实例化就失败了，也就是泛型函数调用就失败了。

泛型函数实例化后就生成了一个非泛型函数，用于真正的函数执行。

Generic Types

类型参数除了用于泛型函数之外，还可以用于 Go 的类型定义，来实现泛型类型。

看如下代码示例，实现了一个泛型二叉树结构：

type Tree[T any] struct {
	left, right *Tree[T]
	data T
}
 
func (t *Tree[T]) Lookup(x T) *Tree[T]
 
var t Tree[string]

二叉树节点存储的数据类型可能是多样的，有的二叉树存储 int，有的存储 string 等等。

使用泛型，可以让 Tree 这个结构体类型支持二叉树节点存储不同的数据类型。

对于泛型类型的方法，需要在方法接收者声明对应的类型参数。比如上例里的 Lookup 方法，在指针接收者*Tree[T] 里声明了类型参数 T。

Type Sets Defined

类型限制往往包含了多个具体类型，这些具体类型就构成了类型集。

Go 1.18 之前，interface 用来定义方法集。

Go 1.18 开始，还可以使用 interface 来定义类型集，作为类型参数的 Type constraint（类型限制）。

比如定义一个整数类型集：

type Signed interface {
	~int | ~int8 | ~int16 | ~int32 | ~int64
}
 
type Unsigned interface {
	~uint | ~uint8 | ~uint16 | ~uint32 | ~uint64 | ~uintptr
}
 
type Integer interface {
	Signed | Unsigned
}

另外，any 是 interface{} 的别名。

| && ~

• | 表示取并集，用于组合多个类型。
• ~ 是 Go 1.18 新增的符号，~T 表示底层类型是 T 的所有类型。

Type Inference

Go 编译器可以通过参数推断出具体的类型，比如 Map[int](1, 2) 直接写成 Map(1, 2) 即可，编译器会从参数 1、2 推断出类型是 int。

类型推导并不是一定成功，比如类型参数用在函数的返回值或者函数体内，这种情况就必须指定类型实参了。

更深入的了解可以参考：https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-inference

Map Reduce

JS：

arr.map(callbackFunc).filter(callbackFunc).reduce(callbackFunc)

Go：

Reduce(Fileter(Map(s, callbackFunc), callbackFunc), callbackFunc)

相对没有那么直观 。

能不能套一个 Container? 实现 C.map().fileter().reduce()

Map

常用于提取一组对象的关键属性，例如 ids

func Map[T, U any](s []T, f func(T) U) []U {
  r := make([]U, len(s))
  for i, v := range s {
    r[i] = f(v)
  }
  return r
}
 
s := []int{2, 4, 8, 11}
ds := Map(s, func(i int) string {return strconv.Itoa(2*i)})

Filter

func Filter[T any](s []T, f func(T) bool) []T {
  var r []T
  for _, v := range s {
    if f(v) {
      r = append(r, v)
    }
  }
  return r
}
 
evens := Filter(s, func(i int) bool {return i % 2 == 0})

Reduce

func Reduce[T, U any](s []T, init U, f func(U, T) U) U {
  r := init
  for _, v := range s {
    r = f(r, v)
  }
  return r
}
 
product := Reduce(s, 1, func(a, b int) int {return a*b})

Some Experience

KeyIndex

以对象的某个字段引用对象，生成一个 map：

eg: KeyIndex([{id: 1}, {id: 2}], func(e) {return e.id}) => {1: {id: 1}, 2: {id: 2}}

func KeyIndex[T any, U comparable](s []T, f func(T) U) map[U]T {
	m := make(map[U]T, len(s))
	for _, v := range s {
		m[f(v)] = v
	}

	return m
}

constraints 包

constraints 包里定义了 Signed、Unsigned、Integer、Float、Complex 和 Ordered 6 个interface 类型。

contraints.Ordered 的定义如下：

type Ordered interface {
    Integer | Float | ~string
}

constraints 包目前已经被移除出标准库（容易被网上很多过时的文章误导，正式版是没有这个包的），为什么被移除呢？

Go 官方团队技术负责人 Russ Cox 在 2022.1.25 发起提议（https://github.com/golang/go/issues/50792 ）：

There are still questions about the the constraints package. To start with, although many people are happy with the name, many are not. On top of that, it is unclear exactly which interfaces are important and should be present and which should be not. More generally, all the considerations that led us to move slices and maps to x/exp apply to constraints as well.

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. The ability to abbreviate simple constraints let us remove constraints.Chan, constraints.Map, and constraints.Slice, which probably would have been commonly used, but they're gone.

Unlike other interfaces like, say, context.Context, there is no compatibility issue with having a constraint interface defined in multiple packages. The problems that happen with duplicate interfaces involve other types built using that type, such as func(context.Context) vs func(othercontext.Context). But that cannot happen with constraints, because they can only appear as type parameters, and they are irrelevant to type equality for a particular substitution. So having x/exp/constraints and later having constraints does not cause any kind of migration problem at all, unlike what happened with context.

For all these reasons, it probably makes sense to move constraints to x/exp along with slices and maps for Go 1.18 and then revisit it in the Go 1.19 or maybe Go 1.20 cycle. (Realistically, we may not know much more for Go 1.19 than we do now.)

Discussed with @robpike, @griesemer, and @ianlancetaylor, who all agree.

总结一下这几个理由：

1. 很多人不喜欢这个包名，constraints 名字太长，代码写起来比较繁琐
2. 对 constaints 包里应该提供哪些 interface 不是很明确
3. 之前放在标准库里是因为：作者认为这个包是使用泛型必不可少的，但是实践中并非如此（实践检验真理），大多数泛型的代码只用到了 any 和 comparable 这两个类型约束。constaints 包里只有constraints.Ordered使用比较广泛，其它很少用。所以完全可以把 Ordered 设计成和 any 以及 comparable 一样内置，不用单独弄一个 constraints 包。而且这样能去除 constaints.Chan、constaints.Map、constaints.Slice 这些约束
4. 没有兼容性问题

另外：

• golang.org/x 下所有 package 的源码独立于 Go 源码的主干分支，也不在 Go 的二进制安装包里。，可以使用 go get来安装。
• golang.org/x/exp 下的所有 package 都属于实验性质或者被废弃的 package，不建议使用。

什么时候使用泛型？

在写 Go 代码的时候，对于泛型，Go 泛型设计者 Ian Lance Taylor 建议不要一上来就定义 type parameter 和 type constraint，先写具体的代码逻辑，等意识到需要使用 type parameter 或者定义新的 type constraint 的时候，再加上不迟。

怎么算意识到呢？

• 除了类型不同，逻辑很相似的函数，MinInt、MinFloat、Sort
• 比如以相似的逻辑操作不同类型的 slice、map、channel
• 通用的数据结构，比如链表，二叉树等

什么时候不使用泛型?

函数的实现逻辑对不同类型不一样时，比如 encoding/json 这个包使用了 reflect，如果用泛型反而不合适。

参考资料

• Tutorial: Getting started with generics
• A Proposal for Adding Generics to Go
• spec: add generic programming using type parameters
• Generics implementation - GC Shape Stenciling
• Type Parameters Proposal