Go 泛型草案更新,明年8月发布的 Go 1.17 将引入

2020年06月18日

Go 团队近日在博客介绍了 Go 泛型的最新进展。

Go 团队表示他们一直在完善泛型的设计草案,并为此编写了一个类型检查器——可按照设计草案中的说明,解析使用泛型的 Go 代码并报告任何类型的错误。为了收集社区的反馈,他们还编写了示例代码并在草案中提供。

根据收集的反馈和了解的信息,Go 团队发布了更新后的泛型设计草案

"The design is fully backward compatible with Go 1",完全兼容 Go 1

新版草案最大的变化是放弃了关于 contracts 的想法。因为团队认为 contracts 和 interface 类型之间的区别会令人感到困扰,所以他们正在消除这种区别。类型参数现在受 interface 类型约束,当 interface 类型仅作为约束(constraints)使用时,可被允许包含类型列表。在旧版的设计草案中,类型列表属于 contracts 的功能。更复杂的情况将使用参数化的 interface 类型.

为了帮助决定如何进一步完善设计草案,团队还发布了翻译工具。此工具可用于类型检查,以及运行使用设计草案中描述的泛型版本编写的代码。它通过将泛型代码翻译为普通的 Go 代码来工作。此翻译过程有一定的局限性,不过团队主要是希望借此让大家对 Go 泛型的整体有所了解。如果泛型最终被吸纳,它们的实际实现可能会有所不同。

此工具已在 Go playground 的变体上提供,这个 playground 的工作方式与常见的 Go playground 相同,不过前者支持泛型代码。团队希望此工具能为 Go 用户提供尝试使用泛型的机会,并了解两件主要的事。

首先,Go 泛型是否有意义,能给用户带去怎样的惊喜,错误提示消息是否有价值;其次,很多人曾说过需要 Go 泛型,但他们不一定确切知道这意味着什么,那么泛型的设计草案是否以有用的方式解决了此问题。另外,假如有一个问题让人认为“如果 Go 具有泛型,我就可以解决此问题”,那么使用此工具是否可以解决问题?

至于具体的推进计划,Go 团队表示要根据从社区收集的反馈而定。如果设计草案受到好评,并且不需要进行重大更改,那么下一步将是正式的语言变更提案

为了保证符合预期,如果每个人都对设计草案完全满意,并且不需要进行任何进一步的调整,则最早可以在计划于2021年8月发布的 Go 1.17 中添加泛型。不过可能存在无法预料的问题,所以这是一个乐观的时间表,团队也无法做出任何明确的预测。

详情查看 https://blog.golang.org/generics-next-step

展开阅读全文
5 收藏
分享
加载中
精彩评论
这个()加的我傻了,就不能换个<>或其他的吗?后面跟3个()我自己的代码都看不下去
2020-06-18 10:16
25
举报
说实话,试了一下,感觉有点强制加入的意味,一个函数要实现泛型,要多加一个(),违背了go的简单原则,有的时候一件好的东西不一定要尽善尽美,如果以为迎合所有的需求,可能就得放弃初衷,到最后就会弄得面目全非。
2020-06-18 08:51
25
举报
func的定义上现在有三个括号了,多一个没啥
golang的目标应该是180个括号的func(接受者)星辰(泛型)(参数 func(func(func(func(func(func(func(func()))))))))(返回值)(大海)
2020-06-18 14:19
7
举报
先入为主的人可能会觉得引入泛型破坏了简洁
2020-06-18 09:59
5
举报
没有泛型,现在的interface{}方式其实也还行
2020-06-18 08:42
5
举报
最新评论 (45)
看各个群里和论坛的评论,对Go2都是褒贬不一。
我想说的是,这是别人的语言,不可能100%符合自己的口味,美帝不卡你脖子已经够意思了。

如果真不爽,就直接操刀ast搞一个自己的定制语言。
gofmt 和 golint 检查也是基于 ast 做分析。
基于 ast 可以扩展出新的语法来,比如七牛面向数据科学语言的 Go+语言。

可以简单看看这本书: https://github.com/chai2010/go-ast-book
其实也就是把 ast 包里的代码简单讲讲。


当然为了写这个书,我们也定制了一个凹语言:目前已经是一个可以嵌入 Go 语言的脚本语言,
也是基于 Go 语言的 ast 定制,在语言的基本功能完成之后我们会公开代码(https://github.com/wa-lang/wa)。
2020-06-23 15:39
1
回复
举报
跟c++ 没啥区别,搞来搞去,都一个样,还是用kotlin 吧,哈哈
2020-06-22 18:45
1
回复
举报
老实说对于Go的大部分开发者来说,有没有泛型并不重要,因为现有的interface机制工作的很好,当然有了泛型,可以简化一部分代码,我还是会用这个特性的。大部分Go语言开发者只是担心这会引入新的复杂度。评论区里有Java、D的开发者不理解很正常,这是Go独有的语言文化。
2020-06-22 09:53
2
回复
举报
这个加()表示泛型是什么鬼?就这么想特立独行吗?这加了完全违反常识了。学其他语言用<>会死啊。
2020-06-21 23:09
3
回复
举报
没有以前版本的包袱,千千万万不搞成Java的类型擦除!!!!!!
2020-06-19 16:42
0
回复
举报
同一件事情,国内和国外评论完全不一样,有趣。国外是用代码和你说事,说你这个方案存在哪些问题;国内是总觉得自己比语言设计者聪明系列,除了指指点点也说不出个所以然。
2020-06-19 11:23
4
回复
举报
是的国人爱抬杠。连抬杠的都抬。
2020-06-19 18:03
3
回复
举报
很简单。现有代码书写模式不适合中国人的书写习惯。就像英语不适合中国人,中国人说中文多,说英语少一样。
2020-06-22 16:18
0
回复
举报
怎么小个地方哪写的下代码,去知乎写还差不多
2020-06-22 16:46
0
回复
举报
谁允许你代表我的?你知道我的想法?
2020-10-20 12:15
0
回复
举报
评论比正文好看.
2020-06-19 08:49
0
回复
举报
或将引入,或将引入,或将引入
2020-06-19 08:44
0
回复
举报
你们这辈子别想看到golang2.x
2020-06-18 17:38
0
回复
举报
走了C++的老路--整体设计有问题,补丁落补丁,最后一团乱。既然提供转换机制,不如只在语法面提供泛型,二进制层泛型并没有优势,倒是增加复杂度。
2020-06-18 15:34
2
回复
举报
更多评论
45 评论
5 收藏
分享
返回顶部
顶部