为什么 Go 的泛型一拖再拖?

开发 前端
信息汇总来看,Go 泛型这几年会出,但大体来讲现在 Go 泛型又又又推迟了。好家伙,我最早了解到时是考虑 Go1.16 释出,后面又推到了 Go1.17,接着现在又延期到了 Go1.18 了(2021 年底)。

大家好,我是从不放鸽子的煎鱼。

前段时间 Go 语言的泛型讨论频频出现在各微信群,且又冲上了国内外各大文章的 “头条”:

信息汇总来看,Go 泛型这几年会出,但大体来讲现在 Go 泛型又又又推迟了。好家伙,我最早了解到时是考虑 Go1.16 释出,后面又推到了 Go1.17,接着现在又延期到了 Go1.18 了(2021 年底)。

看到了信息的表象后,再想想为什么泛型 “这件事情” 突然醒目起来了,其原因之一是由官方 Go,11 岁[1] 的博文所引爆的。

同时近日举办的 GopherCon2020 大会,Robert Griesemer 分享的 Typing [Generic] Go。更正式的让 Go 泛型更面向了大众,也侧面的说明官方认为其已经到达了一个新的阶段了,进入最终实现阶段。

事不宜迟,既然官方都已经摩拳擦掌了,我们的学习之路也得跟上,因此本文将会介绍 Go 泛型现在的情况,并通过在介绍过程中不断思考最后得出一个为什么。

什么是泛型

泛型程序设计(generic programming)是程序设计语言的一种风格或范式。泛型允许程序员在强类型语言中编写代码时,使用一些以后才确定的类型,其在真正实例化时才会为这些参数指确定类型。

另外各语言和其编译器、运行环境对泛型的支持均不一样,因此需要针对来辩证。

简单来讲,泛型就是参数化多态。其可根据实参类型生成不同的版本,支持任意数量的调用:

  1. func F(a, b T) T{ return a+b } 
  2.  
  3. // T 为 int 
  4. F(1, 2) 
  5.  
  6. // T 为 string 
  7. F("1""2"

在编译时期编译器便确定其 T 的入参类型。这也是 Go 泛型实现的要求之一 “编译时类型安全”。

为什么需要泛型

这时候可能会有人说,没有泛型也可以啊...感觉写业务代码没什么影响,与其搞泛型不如搞好 errors(具体新消息可参见:重磅:Go errors 将不会有任何进一步的改进计划)。

但泛型是有其所需的场景,最常见的是像基础库在处理获取配置中心数据时,就要处理类型,时常遇到下述场景:

 

 

手写一个 “泛型”如果使用接口(interface)类型来做,也得 switch.(type) 枚举出所有的基础类型。这显然并不合理,也没法做太复杂的逻辑,而且所支持的类型还泄露。

 

另外同时单从语言层面来讲,泛型支持是一个必然事件了,因为泛型的存在对解决特定领域的问题存在一定的意义。

接口和泛型有什么区别

在上面我们有提到接口(interface)类型,这时候就出现了泛型的第二个经典问题。那就是 “接口和泛型有什么区别?”,为什么不用接口来实现 “泛型”:

  1. type T interface { ... } 
  2. func F(a, b T) T { return a+b } 

也像这么一回事,但在这里存在一个致命的缺陷。那就是接口的入参和出参均可以在运行时表现为不同的类型:

  1. F("煎鱼", 233) 

要做好,还得依靠内部去对参数进行断言,否则作为 string 类型的煎鱼又如何和 int 类型的 233 相加呢,那是必然报错的。

而反过来看真 “泛型” 的实际使用,编译器会保证泛型函数的入参和出参必须为同一类型,有强制性的检验:

  1. // 报错:type checking failed for main 
  2. F("煎鱼", 233) 
  3.  
  4. // 必须为同一类型,才能正常运行 
  5. F(666, 233) 

两者存在本质上的区别,泛型会更安全,能够保证编译早期就发现错误,而不是等到运行时(并且可能会存在隐性的 BUG)。

总体来讲,泛型相较接口有如下优点:

  • 更安全:编译早期就能发现错误。
  • 性能好:静态类型。

过去:为什么那么久都没有泛型

前几段在社区的微信群看到一位小伙伴吐槽 “Go 语言居然没有泛型?”。

变相来看,可能其会认为 ”Go 都已经 11 岁了,2020 年了居然还没有泛型?”。

这显然是不对的,因为泛型本质上并不是绝对的必需品,更不是 Go 语言的早期目标,因此在过往的发展阶段没有过多重视这一点,而是把精力放在了其他 feature 上。

另外 Go 语言在以往其实进行过大量的泛型 proposal 试验,基本时间线(via @changkun)如下:

虽然偶有中断,但仔细一看,2010 年就尝试过,现在 2020 年了,也是很励志了,显然官方也是在寻路和尝试的过程中,但一直没有找到相较好的方案,大多都存在问题,社区对方案的争议也不断。

现在:Go 泛型

泛型尝鲜的方式有两种方式。线上 Ian Lance Taylor 提供了一个在线编译的 go2go[2]:

 

另外一种是线下,也就在本地安装 Go 的特定分支版本:

  1. $ git clone https://github.com/golang/go 
  2. $ git checkout dev.go2go 
  3. $ cd src && ./all.bash 

不过这种本地安装的方法会耗时比较久,初步尝试的话建议使用 go2go 就可以了。

而在尝鲜时,可以看到在代码块中声明了一个 Print 方法,其函数签名主体分为三部分:

 

 

函数签名

 

咋一看,变量 T 的这个关键字 any 是什么?早期泛型你可能有听说合约(Contract),难道这就是合约。其实严格意义上来讲并不是,因为为了更一步简化语法,合约在 2020.06.07 已经正式移除。

其已改头换面,现在只需要写参数化的 interface。而上述的 any 关键字是一个预定义的类型约束,声明后将允许任何类型用作类型实参,并且允许函数使用用于任何类型的操作。

从语法分析的角度来讲,Print 方法一共包含了如下属性(从左到右):

  • type list:声明了入参的类型列表为一个 T 变量,其可以传任意类型的参数。
  • parameter list:声明了入参的参数列表为 T 变量的切片,且形参为 s。
  • return type list:声明了函数的返回参数列表。

上述函数签名便是一个 Go 泛型的基本样子,由于本文并不是 CRUD 泛型,便不展开案例(且现有泛型还不成熟)。

若大家有兴趣,强烈建议阅读提案:Type Parameters - Draft Design[3]。

泛型的战争

为什么不用尖括号

在社区中很多同学在讨论的一个问题,那就是 “为什么 Go 泛型不像 C++ 和 Java 那样使用尖括号?,也出现了 “Go 一直标榜业界工程实践类的榜样,为什么就是不用尖括号” 的言论?

思考问题我们不只看表面,官方说不行,那么我们可以倒推来看,看看 Go 语言就用尖括号:

  1. func print<type T>(list []T) { 
  2.  
  3. print<int>(numbers) 
  4. print<string>(strings) 
  5. print<float64>(floats) 

普通的函数声明看上去似乎结构清晰,没有什么大问题的。接着往下看:

  1. a := w < xb := y > (z) 

我们继续把代码演进一下,简洁一点:

  1. a, b := w < x, y > (z) 

这时候就犯难了,不仅编译器难以解析,人也很难判别,到底指的是:

  1. a := w < xb := y > (z) 

又或是:

  1. a, b := w(z) 

从上述代码来看,使用尖括号难以分别,因为没有类型信息,就无法确定赋值的右侧是一对表达式 w < x和y > (z),还是返回两个结果值 w(z) 的泛型函数实例化和调用,其存在歧义。

要解决还要引入新的约束,会破坏 Go1 的兼容性承诺,这显然是不合理的。

为什么不用括号

其实最早 Go 泛型的版本是使用了括号的模式,虽然能用,但是用括号会引入新的解析歧义。例如:

  1. var f func(x(T)) 

从语法上来讲,你无法识别他是未命名参数的 x(T) 函数,还是类型名为参数的 (T) 函数。

同时 Go 语言还存在强制类型转换这一语法,假设代码是 []T(v1) 和 []T(v2){} ,那么你在开括号处,就无法得知其是否代表类型转换。

甚至在函数的完整声明上,我们都会感到困惑:

  1. func F(T any)(v T)(r1, r2 T) 

函数入参、泛型、返回值声明均都是括号,造成了语义不清,这显然也是不合理的。

为什么不用书名号(«»)

想的美,并不想使用非 ASCII,未来更没打算支持。

总结

在本文中我们从多个维度介绍了 Go 泛型的相关内容,既了解到了上段时间 Go 泛型再度火爆的信息来源是什么。也知道了 Go 泛型是什么,与接口的区别。

同时我们还针对业界常见的一些疑问,例如接口和泛型的区别,泛型的历史,泛型的尖括号/括号/书名号之争进行了解释和说明。

最后我们回答一下最开始的疑问,”为什么 Go 的泛型一拖再拖“,主要如下:

  • Go 语言的早期目标(工作重点)并不是泛型。
  • Go 语言在 2010-2020 年都有间断在做 Go 泛型的 proposal,但总是 ”失败“,在不断地吸收经验。
  • Go 语言社区的意见反馈是真的多,单用什么符号表示泛型,不想要泛型都争论不休。
  • Go 语言的泛型现在还不成熟,很多细节其实并没有支持好。

很显然,在保证 Go1 向后兼容性的同时,Go 官方也不想直接妥协出一个随便的方案,因此总是不断地在改进。

随着 Go 语言的在业内的不断应用,泛型也和 errors 一样被推上风头浪尖。

到底拖到什么时候

那 Go 泛型到底什么时候出呢?前段时间也向欧神(@changkun)了解到:

在 GopherCon 2020 Go Team AMA 时,russ cox 有聊到相关问题,表示在明年年底要能有生产环境的试用版上线,这是一个管理目标。

但具体真正的时间线肯定是要看泛型的实现者:robert 和 keith,可以多多关注他们,就能拿到一手信息,且可以确定的是 Go 泛型明年二月之前是不会有生产可用的试用版。

最后,灵魂拷问:你对 Go 语言的泛型又有什么想法和意见呢,一起留言讨论吧。

责任编辑:未丽燕 来源: 脑子进煎鱼了
相关推荐

2020-03-02 14:18:33

程序员技能开发者

2020-09-27 16:40:29

程序员技术开发

2009-02-12 14:41:00

安腾英特尔惠普

2021-05-27 19:39:58

MWC21世界移动大会移动通信

2015-02-04 10:46:59

AppleWatchuber

2021-09-29 18:17:30

Go泛型语言

2009-06-02 09:16:58

Firefox浏览器

2012-06-28 10:48:31

设计交互设计

2023-09-06 12:57:11

AI训练

2011-01-27 09:16:04

微软云计算

2018-11-30 16:19:03

App启动SDK

2021-12-05 23:45:23

Go泛型Maps

2023-09-18 09:00:59

2011-07-21 15:13:43

机房数据中心服务器

2023-11-29 08:19:45

Go泛型缺陷

2011-03-01 10:19:10

2018-11-27 10:25:05

2024-10-28 00:40:49

Go语法版本

2010-03-10 09:54:38

APC

2015-12-01 10:00:21

点赞
收藏

51CTO技术栈公众号