Go 编译器已默认启用 -G=3,支持泛型

来源: OSCHINA
编辑: 局长
2021-08-22

Go 项目代码仓库昨日提交和合并的一个 PR 显示,Go 语言已在 cmd/compile 中默认启用 -G=3。

根据描述,此 PR 将 cmd/compile 的 -G flag 的默认值从 0 改为 3,因此可以使用新的 types2 类型检查器并支持类型参数,即启用了对泛型的支持。旧的类型检查器仍然可以通过 -gcflags=all=-G=0 使用。该变更还更新了回归测试工具,主要是出于对默认行为变化的考虑(例如,types2 类型检查器已知的变更)。

不过,-G=0 模式目前仍在测试中。

其实上周 Go 1.17 发布时,开发者就发现泛型代码已被合并:

HN 上的相关讨论:https://news.ycombinator.com/item?id=28253692

展开阅读全文
4 收藏
分享
加载中
精彩评论
大道至简是用来勾引程序员的。等到骗到人了,衣服终究还是会穿上去的。
2021-08-22 11:52
23
举报
I_I
官方已经解释了为什么不用尖括号,而用方括号,并不是人家水平低、也并不是人家没你们懂,而是一个取舍的问题。
golang最大的特色之一就是编译速度快,如果范型使用尖括号,在某些情况下需要unbounded lookahead,会显著影响编译速度,所以放弃了使用尖括号。
2021-08-23 10:57
4
举报
啥时候再加上异常处理?
2021-08-23 10:22
4
举报
agree.
一直觉得能造出v8的公司分分钟就能解决反射的性能问题.
结果. 连个括号都将就.
2021-08-23 09:58
4
举报
搞语言不是拉帮结派 也不是搞什么哲学 有的时候接受别人的批评是一种好事
2021-08-25 10:59
3
举报
最新评论 (46)
为啥支持范型就不简洁了呢?类型检查能让你少犯一些类型匹配的错误,减少各种类型断言,使代码更可预测,不是更简洁么?
2021-08-23 20:38
0
回复
举报
减少类型断言? 你的想法太可怕的了
2021-08-31 12:17
0
回复
举报
没有泛型之前,都是 interface{} ,都得断言,即使你知道具体的类型。
2021-08-31 15:32
0
回复
举报
这年代还有新出来的现代静态语言不支持泛型,好意思出来混?
2021-08-23 17:48
1
回复
举报
卧C……放长线钓大鱼么
2021-08-23 17:03
0
回复
举报
go vs rust 还欠缺很多功能,标准库也很弱
2021-08-23 15:21
0
回复
举报
屠龙少年最终成了恶龙
2021-08-23 14:46
1
回复
举报
支持加入泛型 完善类型系统 但有一说一 go语言大道至简就是骗人的 go没有指针?没有引用?虽然多了一个泛型是好事 但异常处理也是稀烂
2021-08-23 12:32
3
回复
举报
不用就行了,我用自己喜欢的PHP美滋滋
2021-08-23 15:20
1
回复
举报
一句话,假如你不理解Go的哲学,那就说明你适合用别的语言。
2021-08-25 09:21
1
回复
举报
搞语言不是拉帮结派 也不是搞什么哲学 有的时候接受别人的批评是一种好事
2021-08-25 10:59
3
回复
举报
别动不动就扯到哲学上,语言的设计问题本来就是可以讨论的,装什么哲学家呢
2021-08-26 17:47
2
回复
举报
啥时候再加上异常处理?
2021-08-23 10:22
4
回复
举报
小鲜肉到中年,也会变油腻大叔。。
2021-08-23 10:08
2
回复
举报
666
2021-08-23 08:18
0
回复
举报
我觉得有反射就可以了,并不需要泛型。只会让精简的语言越来越臃肿。
2021-08-23 01:23
2
回复
举报
泛型可以在编译的时候就确定类型,这是反射无法比拟的性能,这也是为什么其他有了反射仍然需要泛型
2021-08-23 07:20
1
回复
举报
agree.
一直觉得能造出v8的公司分分钟就能解决反射的性能问题.
结果. 连个括号都将就.
2021-08-23 09:58
4
回复
举报
I_I
官方已经解释了为什么不用尖括号,而用方括号,并不是人家水平低、也并不是人家没你们懂,而是一个取舍的问题。
golang最大的特色之一就是编译速度快,如果范型使用尖括号,在某些情况下需要unbounded lookahead,会显著影响编译速度,所以放弃了使用尖括号。
2021-08-23 10:57
4
回复
举报
官方解释可不是什么速度. 而是Resolving that requires effectively unbounded lookahead. In general we strive to keep the Go parser simple. 不想增加编译器复杂度.
2021-08-23 16:44
0
回复
举报
Rust语言开发者对go这个问题的看法:
"They are wrong in this case.

When considering whether to allow `foo<T>();` in Rust, we measured the performance impact that infinite look-ahead / backtracking would have in that case. The result was negligible.
...."

原文讨论: https://news.ycombinator.com/item?id=23840243&p=2
2021-08-23 16:48
0
回复
举报
I_I
“keep the Go parser simple”的最终目的就是为了编译速度,编译器的复杂度增加会影响编译速度,特别是遇到需要unbounded lookahead的时候,对编译速度的影响会显著增加。编译器的复杂度增加又不会增加开发者的学习成本。
我们三十多万行的项目代码,在普通开发机器上的编译速度最慢也就十多秒,如果泛型导致编译速度拖慢1秒,那编译时间就会增加10%左右。
Rust的编译时间基本上跟C++同数量级的,以前一个项目编译一两个小时太正常了(这也就是为什么Go的创始人将编译速度定位优先目标),泛型增加的几秒钟对于以小时计的编译速度,可不就是“negligible”么?
2021-08-23 18:06
2
回复
举报
泛型可以避免反射的性能损失,也可以避免人为的类型匹配错误,也能让代码更精炼,个人认为,语法简单但写法啰嗦的语言叫简陋的语言,而不是精简的语言
2021-08-24 08:19
3
回复
举报
更多评论
46 评论
4 收藏
分享
返回顶部
顶部