第 8 章泛型 on Go 语言原本

8.1 泛型设计的演进

Mon, 01 Jan 0001 00:00:00 +0000

8.1 泛型设计的演进

泛型是 Go 等待最久、争论最烈、也最能体现其设计哲学的一项特性。从 2009 年开源到 2022 年的 Go 1.18 才落地，这十三年的迟疑与最终的取舍，本身就是一堂语言设计课。这一节回答三个问题： Go 为何久久不加泛型、最终怎样加的、它在底层又是如何实现的。后者尤其关键，因为 Go 的实现没有照搬任何一家成例，而是走了一条独特的中间道路，这条道路才是它对那个十三年难题的真正回答。设计本身一路如何演变（合约、类型集、多轮语法提案），留待 8.4 细说，本节只取其骨架。

8.1.1 久拖不决：泛型的两难

缺了泛型，写一段对多种类型行为相同的代码会变成什么样？最直接的办法是为每个类型各抄一份：

1
2
3
4


func MaxInt(a, b int) int { if a > b { return a }; return b }
func MaxFloat64(a, b float64) float64 { if a > b { return a }; return b }
func MaxUintptr(a, b uintptr) uintptr { if a > b { return a }; return b }
// ……每多一个类型，就多抄一份逻辑相同的代码

逻辑一字不差，只有类型不同。第二条路是用 interface{} 把类型差异抹掉，让一份代码服务所有类型：

8.2 基于合约的泛型

Mon, 01 Jan 0001 00:00:00 +0000

8.2 基于合约的泛型

本节内容另有一份配套的线上演讲：YouTube 在线、 Google Slides 讲稿。讲稿录于合约提案尚在讨论的 2019 年，与本节互为印证。

8.1 用一句话带过了「先有合约、后转向接口即约束」这段演进。这一节把那句话展开：合约究竟长什么样、它有多强的表达力、又为何最终被放弃。这段被否决的设计不是历史的废料，它解释了今天 [T Ordered] 语法的由来，也示范了 Go 设计中一个反复出现的动作,先做出一个表达力很强但偏复杂的方案，再回头追问「这件事能不能用已有的概念表达」，逼着复杂度去赚取自己存在的资格。

本节展示的所有 contract 语法都已废弃，仅出现在 2018 年至 2020 年的 go2draft 草案里， 任何一个 Go 编译器都从未接受过它们。下文凡是合约写法，都按其在草案中的原貌呈现，并明确标注「已废弃」，以免与今天可用的语法混淆。

8.2.1 约束想解决什么

泛型函数迟早要回答一个问题：类型参数 T 能做哪些操作？写一个求最大值的 Max，函数体里要用到比较运算符 <，可 T 若被实例化成一个不支持比较的类型（比如某个 struct 或 slice），这段代码就不成立。于是泛型机制必须提供一种手段，让作者声明 T 必须支持哪些操作，并让编译器据此在实例化处做检查。这就是「约束」（constraint）。

约束不是可有可无的修饰。没有它，泛型只剩两条退路：要么像 C++ 早期模板那样完全不约束，类型错误推迟到实例化时才以一长串难懂的报错暴露出来；要么像 interface{} 那样放弃静态信息，靠运行时断言兜底，把类型安全和性能一并丢掉（8.1 的两难）。约束的价值，正是把「T 得能做什么」这件事提前到声明处讲清楚，让错误在调用点就被拦下，也让编译器有依据生成正确的代码。问题只剩一个：用什么语法把这组要求写出来。

8.2.2 合约：一段不会执行的代码

2018 年 go2draft 给出的第一版答案，是引入一个新关键字 contract。合约形如一个函数：它带一组类型参数，函数体里罗列这些类型必须满足的条件。以 Max 为例，最朴素的设想是直接在体内写出要用到的运算符（这是草案探讨过的更早一版写法）：

8.3 类型检查技术

Mon, 01 Jan 0001 00:00:00 +0000

8.3 类型检查技术

泛型给类型检查器出了远比从前难的题。从前的判断只有一种形状：「这个值是不是这个类型」。有了类型参数，检查器还得回答三个新问题：一个类型实参是否满足约束、a + b 这样的运算在未知类型上是否成立、以及调用 Max(3, 5) 时那个没写出来的 T 到底是什么。这三件事分别对应本节的三个主题：类型集、核心类型、类型推断。它们是 8.1 那套设计落到编译期的具体技术，也是 15 编译器前端的前奏。

贯穿本节的标尺只有一句：泛型让类型系统的复杂度陡增，而 Go 把这份复杂度尽量关在编译器内部，不让它溢出到用户面前。读完应当能说清，这份「关」是靠哪几样技术做到的。

8.3.1 类型集：约束是一个类型的集合

约束的核心概念是类型集（type set）。一个普通接口描述「有哪些方法」，约束接口则进一步描述「哪些类型属于我」。把接口从方法集推广为类型集（8.1.2），是让既有的接口语法直接承载约束的关键一步。

类型集由类型项（type term）的并集构成。spec 把类型项的语义定得很干净，编译器 cmd/compile/internal/types2 里的 term 结构原样照搬了这套集合论记号：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// types2/typeterm.go：一个类型项描述一个最基本的类型集（速写）
//
// ∅: (*term)(nil) == ∅ // 空集
// 𝓤: &term{} == 𝓤 // 全集（所有类型）
// T: &term{false, T} == {T} // 恰好是 T 这一个类型
// ~t: &term{true, t} == {t' | under(t') == t} // 底层类型为 t 的所有类型
type term struct {
 tilde bool // 仅当 typ != nil 时有效
 typ Type
}

于是约束里的三种写法各自对应一种类型项：int 是单点集 $\{\texttt{int}\}$；~int 是 $\{t \mid \mathrm{under}(t) = \texttt{int}\}$，即所有底层类型为 int 的类型（~ 取的就是 underlying，故 type Celsius float64 落在 ~float64 里）；A | B 是并集 $S_A \cup S_B$。 spec 对 ~T 有两条硬约束：T 的底层类型必须是它自己（~MyInt 非法），且 T 不能是接口（~error 非法）。一个约束接口的最终类型集，是它各类型项并集与各方法所蕴含集合的交集：

8.4 泛型的未来

Mon, 01 Jan 0001 00:00:00 +0000

8.4 泛型的未来

本节内容对标 Go 1.26。泛型自 1.18 落地至今已逾四年，本节不再停留在「将会怎样」的猜想，而是回过头清点：哪些设想兑现了、哪些被有意搁置、以及那个贯穿始终的张力（抽象的代价）今天走到了哪一步。本节作者早年曾就 Go 2 泛型做过一次公开演讲（YouTube、讲稿），如今多数预言已可对照现实检验，下文一并交代。

8.1 讲过泛型从合约到「接口即约束」的十三年演进，8.3 讲过类型检查器如何消化类型参数与约束。落地之后的故事则是另一条线：一项语言特性发布只是起点，它在标准库里长出哪些惯用法、社区在使用中撞见哪些边界、团队又据此添了什么、按下了什么，这些才决定它最终的形状。Go 团队对泛型一向自陈谨慎：先发布最小可用的一版，看真实需求浮现，再小步添加。本节就沿着「已落地、仍缺席、核心张力、演进哲学」四条来盘点这份谨慎换来了什么。

8.4.1 自 1.18 以来落地了什么

泛型在 1.18 只交付了语言层的类型参数与约束。真正让它进入日常代码的，是随后几个版本围绕它长出的标准库与惯用法。

slices、maps、cmp：泛型标准库（1.21）。 在泛型之前，「对任意切片排序、查找、去重」要么靠 sort.Slice 加闭包、要么靠 interface{} 加反射，两条路都既不安全也不快。1.21 把这些操作收进三个泛型包。cmp 给出有序类型的约束与比较原语：

1
2
3
4
5
6
7
8


// cmp 包：把「可比较大小」抽象成一个约束（速写自 src/cmp）
type Ordered interface {
 ~int | ~int8 | ~int16 | ~int32 | ~int64 |
 ~uint | ~uint8 | ~uint16 | ~uint32 | ~uint64 | ~uintptr |
 ~float32 | ~float64 | ~string
}

func Less[T Ordered](x, y T) bool { return (isNaN(x) && !isNaN(y)) || x < y }

注意约束里每一项都带波浪号 ~，意为「底层类型为此」而非「恰为此」，于是用户自定义的 type Celsius float64 也落在 Ordered 之内。slices 与 maps 则建在这套约束之上，给出类型安全、无反射的常用操作：

8.5 进一步阅读的参考文献

Mon, 01 Jan 0001 00:00:00 +0000

12.5 进一步阅读的参考文献

[Stroustrup 1994]	Stroustrup, Bjarne. The design and evolution of C++. Pearson Education India, 1994.
[Cox, 2009]	Russ Cox. "The Generic Dilemma." December 3, 2009. https://research.swtch.com/generic
[Taylor, 2010]	Ian Lance Taylor. "Type Functions." golang/proposals, June 2010. https://github.com/golang/proposal/blob/master/design/15292/2010-06-type-functions
[Taylor, 2011]	Ian Lance Taylor. "Generalized Types."golang/proposals, March 2011. https://github.com/golang/proposal/blob/master/design/15292/2011-03-gen
[Cox, 2012]	Russ Cox. "Alternatives to Dynamic Code Generation in Go." September 2012. https://docs.google.com/document/pub?id=1IXHI5Jr9k4zDdmUhcZImH59bOUK0G325J1FY6hdelcM
[Taylor, 2013a]	Ian Lance Taylor. "Generalized Types In Go." golang/proposals, October 2013. https://github.com/golang/proposal/blob/master/design/15292/2013-10-gen
[Taylor, 2013b]	Ian Lance Taylor. "Type Parameters in Go." golang/proposals, December 2013. https://github.com/golang/proposal/blob/master/design/15292/2013-12-type-params
[Pike, 2014]	Rob Pike. "Go Generate." January 2014. http://golang.org/s/go1.4-generate
[Mills, 2016]	Bryan C. Mills. "Compile-time Functions and First Class Types." golang/proposals, September 2016. https://github.com/golang/proposal/blob/master/design/15292/2016-09-compile-time-functions
[Taylor, 2016]	Ian Lance Taylor. "Go should have generics." golang/proposals, January 2011. https://go.googlesource.com/proposal/+/b571c3273d2c6988d24a22dd1c529387ff05962a/design/15292-generics Updated: April 2016. https://github.com/golang/proposal/blob/master/design/15292-generics
[Cox, 2018]	Russ Cox. "Generics — Problem Overview." golang/proposals, August 27, 2018. https://github.com/golang/proposal/blob/master/design/go2draft-generics-overview
[Taylor and Griesemer, 2018]	Ian Lance Taylor, Robert Griesemer. "Contracts — Draft Design." golang/proposals, August 27, 2018. https://go.googlesource.com/proposal/+/4a530dae40977758e47b78fae349d8e5f86a6c0a/design/go2draft-contracts
[Taylor and Griesemer, 2019]	Ian Lance Taylor, Robert Griesemer. "Contracts — Draft Design." golang/proposals. July 31, 2019. https://github.com/golang/proposal/blob/master/design/go2draft-contracts
[Crowd, 2019a]	Go Community. Summary of Go Generics Discussions. living document. https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/view#
[Crowd, 2019b]	Go Community. ExperienceReports. living document. https://github.com/golang/go/wiki/ExperienceReports#generics, https://github.com/golang/go/wiki/Go2GenericsFeedback

第 8 章 泛型 on Go 语言原本

8.1 泛型设计的演进

8.1 泛型设计的演进

8.1.1 久拖不决：泛型的两难

8.2 基于合约的泛型

8.2 基于合约的泛型

8.2.1 约束想解决什么

8.2.2 合约：一段不会执行的代码

8.3 类型检查技术

8.3 类型检查技术

8.3.1 类型集：约束是一个类型的集合

8.4 泛型的未来

8.4 泛型的未来

8.4.1 自 1.18 以来落地了什么

8.5 进一步阅读的参考文献

12.5 进一步阅读的参考文献

第 8 章泛型 on Go 语言原本