条件

我们正在努力开发Go 1.13，我希望它将在今年8月初发布。 这是第一个发行版，在长期暂停任何此类更改之后，将特别包含语言方面的更改（而不仅仅是对规范的微小更改）。

为了实现语言上的这些变化，我们根据“ Go 2来了，我们来了 ！”一文中描述的新提案评估流程，从几张更大的Go 2报价清单中选择了一些可行的提案。 我们希望我们最初选择的提案发挥相对较小的作用，并且在大多数情况下不会引起争议，因此很有可能在整个过程中进行。 提议的更改必须向后兼容，以便尽可能减少故障，因为这些模块 （以后将允许您为特定模块选择语言版本）还不是默认的构建模式。 简而言之，当前的变更初始阶段更多地是为了重新起步并获得经验，而不是解决重大问题。

我们最初的句子列表 - 通用形式的Unicode标识符 ， 二进制整数文字 ， 数字文字的分隔符， 带符号整数的位移位 -已缩短和扩展。 关于Unicode的标识符的通用提议由于无法及时起草设计文件而无法幸免。 关于二进制整数文字的建议已得到极大扩展，并导致对Go数值文字的语法进行了全面的审查和现代化。 我们还添加了Go 2错误检查提议草案，该提议已被部分接受。

考虑到Go 1.13的这些初始更改，现在该考虑Go 1.14的未来并确定下一步要更改的内容了。

Go 1.14的建议

我们今天为Go设定的目标与2007年相同： 使软件开发具有可扩展性 。 改进Go的可伸缩性的三个主要障碍是缺少软件包和版本管理系统，对更好的错误处理系统的支持以及泛型。

随着Go模块系统的改进，解决了管理软件包和版本的问题。 保持改进的错误处理和泛型。 我们在这两个问题上都进行了研究，并在去年的丹佛GopherCon上提出了设计文件草案 。 从那时起，我们逐渐改进了它们。 关于错误处理，我们发布了经过重大修订和简化的提案（请参见下文）。 至于非专利药，我们正在研究中，Ian Lance Taylor的“ Generics in Go”将在今年的圣地亚哥GopherCon上就这一主题发表演讲，但我们还没有达到可以提出具体建议的阶段。

我们还希望继续逐步改善语言本身。 对于Go 1.14，我们选择了以下优惠：

＃32437 。 内置的错误检查功能是“ try”（ 设计文档 ）。

这是我们改善错误处理的建议。 尽管建议的向后兼容语言扩展很小，但我们希望对错误处理代码产生重大影响。 该提案已经引起了大量评论，而要遵循它并非易事。 我们建议从第一个注释开始进行简要描述，然后阅读详细的设计文档。 第一条评论有几个链接，其中包括评论摘要。 在回复之前，请遵循反馈准则（请参阅“后续步骤”部分）。

＃6977 。 允许嵌入重叠的接口（ 设计文档 ）。

这是一个较旧的向后兼容提议，旨在使嵌入接口更具容忍性。

＃32479 。 警告将格式string(int)转换为go vet 。

为了方便起见，很久以来一直在Go中添加了格式string(int)转换，但是对于初学者来说，这非常令人困惑（ string(10)是"\n" ，而不是"10" ）并且不再合理，因为现在该转换在unicode/utf8包中可用unicode/utf8 。 由于删除此转换不是向后兼容的更改，因此我们建议在执行go vet时抛出错误。

＃32466 。 接受密码学设计原则（ 设计文件 ）。

这是对我们希望接受的一组密码库设计原则的反馈请求。 另请参见有关从crypto/tls 删除SSLv3支持的相应建议 。

后续步骤

我们正在积极收集有关所有这些建议的反馈。 我们尤其对有证据表明该提案为何无法在实践中或在开发时可能会错过的问题方面表现不佳感到特别感兴趣。 有说服力的例子支持建议也很有帮助。 另一方面，仅包含个人意见的评论效果较差：我们可以将其考虑在内，但不能与他们进行建设性的合作。 在回答之前，请花一点时间阅读详细的设计文档和以前的评论或摘要。 您的主题可能已经在先前的评论中提出和讨论过，尤其是在长时间讨论中。

如果这些建议没有遇到明显的问题，那么我们计划在开发周期Go 1.14（2019年8月上旬）开始时实施所有措施，以便可以在实践中对其进行评估。 根据评估提案的过程，最终决定将在开发周期结束时（2019年11月上旬）做出。

感谢您帮助改善Go语言！

Robert Griesemer，代表Go团队