第 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 久拖不决：泛型的两难

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

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 把这份复杂度尽量关在编译器内部，不让它溢出到用户面前。读完应当能说清，这份「关」是靠哪几样技术做到的。三个新问题与三样技术一一对应，构成本节的骨架：

flowchart LR
    Q1["实参是否满足约束？"] --> T1["类型集<br/>type set：约束即一个类型的集合"]
    Q2["a + b、range s 在未知类型上是否成立？"] --> T2["核心类型<br/>core / common underlying type"]
    Q3["Max(3, 5) 里的 T 是什么？"] --> T3["类型推断<br/>函数实参合一 + 约束类型推断"]
    T1 --> IMPL["types2：编译器内置、懂泛型的类型检查器"]
    T2 --> IMPL
    T3 --> IMPL

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

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

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

8.4 泛型的未来

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

8.4 泛型的未来

泛型自 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 给出有序类型的约束与比较原语：

// 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 章 泛型 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 章泛型 on Go 语言原本