大家好，我是建宇。前段时间根据Go泛型的最新进展，写了一篇文章《出泛型后 API 怎么办?Go 开发者要注意了》，引起了很多小伙伴的热议。Go核心开发团队现任负责人@RussCox在golang-dev正式发布《expectations for generics in Go 1.18》给出了对Go泛型的“期待”。其实你可以把它看成是对后续泛型的配套迭代计划。如果没有严重问题，Go1.18将包括对泛型的支持，而这种对泛型的支持将是有史以来最大的语言变化。存在以下问题：最佳实践。生产经验兼容性承诺。接下来剑鱼就带大家一起了解一下RussCox发表的Go泛型流程，了解一下官方的第一手消息。BestPracticesGo团队表示，他们不知道使用泛型的最佳实践是什么，所以给出的官方文档将无法准确明确地回答什么时候使用泛型，什么时候不使用泛型，只能给一个粗略的指导。这里可以参考的原版，是在不间断的写了整整一年的Go代码后正式输出的。根据现有计划，官方只会提供如何使用泛型的文档，暂时无法提供任何风格和最佳实践的规范性文档。在提供的标准库上，通过提案的maps和slices库会先放在golang.org/x/exp作为实验，不保证向后兼容。成熟后会扩展到标准库中。很明显，Go泛型出来之后，社区会开始蓬勃发展，然后就会有官方的输出推荐方法。历史是如此相似。生产经验目前Go团队没有泛型的生产经验，所以会在文档中给出明确的提示，让大家在生产中使用泛型时要谨慎。泛型出来之后，会陆续涉及到大量的重写工作，但是因为现在处于中期阶段。将正在重写的Go1.18工具链适配泛型和非泛型代码需要时间和经验，并且存在一定的风险。所以，泛型出来后，可能会出现一些意想不到的问题，只有在生产（课程）中才会发现。兼容性承诺Go1.18将像其他Go1.x版本一样，保证向后兼容性的承诺：不会破坏使用Go1.18构建的代码，包括使用泛型的代码。如果是最坏的情况，如果你发现Go1.18的语义有一些致命的问题，需要改变它们（例如：在Go1.19中）。go.mod文件的go行将用于确定模块中的源文件是否期望Go1.18或Go1.19+语义进行版本控制。但目前，没有必要这样做。也建议急于使用Go泛型的开源库作者做好泛型和非泛型版本代表的支持和隔离工作，这样会更加人性化。综上所述，很明显Go泛型的整体推广方案在这篇文章中已经说明了。Go官方团队也与很多第三方工具作者进行了交流。到Go1.18发布时，第三方工具可能无法完全支持泛型，这取决于每个作者根据自己的时间表进行更新。炸鱼猜的节奏是：支持泛型语法。观察。推进标准/工具库。逐渐取代。修复错误。观察、优化可用生产。大概需要2~3个Go版本，1~2年时间，Go泛型的各种配套组件会基本完善、可用，并转化为持续优化。
