Go 1.15 的提议
Robert Griesemer,代表Go团队
2020年1月28日
状态
我们已经接近Go 1.14版本,如果一切顺利,计划在2月发布,RC1候选版本几乎已经准备就绪。按照Go 2,我们来了!博客文章中概述的过程,这又是我们开发和发布周期中考虑的时候我们是否希望在下一个版本Go(第1.15版)中添加语言和库更改,并计划于今年8月发布。
Go的主要目标仍然是程序包和版本管理,更好的错误处理支持以及泛型。模块支持状况良好,并且每天都在不断完善,我们在仿制药方面也正在取得进展(今年晚些时候会取得更多进展)。我们七个月前尝试提供更好的错误处理机制,try
提案,得到了良好的支持,但也遭到了强烈反对,因此我们决定放弃它。其后有许多后续建议,但它们似乎都没有足够的说服力,明显优于try
提案,或者不太可能引起类似的争议。因此,我们暂时没有进一步追求错误处理的变化。也许将来的一些见识将有助于我们改善现状。
提案
鉴于模块和泛型正在积极开发中,并且由于错误处理暂时无法进行更改,我们还应该进行其他哪些更改(如果有)?有一些常年的收藏夹,例如对枚举和不可变类型的请求,但是这些思想还没有得到充分发展,它们也没有足够紧迫以引起Go团队的大量关注,尤其是在考虑制作语言的成本时更改。
在审查了所有可能可行的提案之后,更重要的是,由于我们不想在没有长期计划的情况下逐步增加新功能,因此得出结论,这次最好不进行重大更改。相反,我们专注于几个新的vet
检查和对语言的较小调整。我们选择了以下三个建议:
#32479。在go vet
中诊断string(int)
转换。
我们计划在即将发布的Go 1.14版本中做到这一点,但我们并没有解决这个问题,因此再次出现。为了方便起见,string(int)
转换是在Go的早期引入的,但是它会使新来的人感到困惑(string(10)
是“ \ n”
不是“ 10”
),并且由于转换在unicode / utf8
包中可用,因此不再合理。由于删除此转换不是向后兼容的更改,因此我们建议从vet
错误开始。
#4483。在go vet
中诊断不可能的接口-接口类型断言。
当前,Go允许以x
和T
的类型为接口的任何类型断言x。(T)
(以及相应的类型转换大小写)。但是,如果x
和T
都具有相同名称但签名不同的方法,则分配给x
的任何值都不可能也实现T
;这样的类型断言将始终在运行时失败(紧急或评估为false
)。由于我们在编译时就知道这一点,因此编译器也可能会报告错误。在这种情况下报告编译器错误不是向后兼容的更改,因此我们还建议从vet
错误开始。
#28591。使用常量字符串和索引对常量和索引表达式进行常量求值。
当前,用一个或多个常量索引对常量字符串进行索引或切片会分别产生非常量byte
或string
值。但是,如果所有操作数都是常量,则编译器可以对这些表达式进行常量求值,并产生常量(可能是无类型的)结果。这是完全向后兼容的更改,我们建议对规范和编译器进行必要的调整。
(更正:我们在发布后发现此更改不向后兼容;有关详细信息,请参见comment。)
时间线
我们认为,这三个建议中没有一个引起争议,但是我们总是有机会错过一些重要的东西。因此,我们计划在Go 1.15发行周期的开始(在Go 1.14发行时或之后)实施建议,以便有足够的时间收集经验并提供反馈。根据提案评估流程,最终决定将在2020年5月初的开发周期结束时做出。
还有一件事情…
我们收到了更多的语言更改建议(标记为LanguageChange的问题),我们无法对其进行彻底审查。例如,仅就错误处理而言,就有57个问题,其中五个问题目前仍未解决。由于进行语言更改的成本,无论大小如何,都很高,而且收益往往不清楚,因此我们必须谨慎行事。因此,大多数语言更改建议迟早都会遭到拒绝,有时反馈很少。这对所有有关方面都不令人满意。如果您花费大量时间和精力详细概述了您的想法,最好不要立即拒绝它。另一方面,由于一般的提案流程刻意简单,因此创建仅少量的语言更改提案非常容易进行了探索,导致审查委员会进行了大量工作。为了改善每个人的体验,我们添加了一个新的questionnaire:语言更改:填写该模板将有助于审阅者对提案进行更有效的评估,因为他们不需要自己尝试回答这些问题。希望它能从一开始就设定期望,从而为提议者提供更好的指导。这是一个实验,我们会根据需要随着时间的推移进行完善。
感谢您帮助我们改善 Go 体验!
本译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
推荐文章: