一年前（昨天），Russ Cox 提交了一个提案，为 Go 添加两个新的range功能：range-over-int和range-over-func。前者已添加到Go 1.22中，而后者让作者立即产生怀疑。

假设

1. 丑陋的接口名称：接口名称令人烦恼，如Seq0、Seq[V any]、Seq2[K, V any]等，类似于 Perl 中令人困惑的open2和open3，可能导致在编写 Go 迭代器时出现问题。
2. 陡峭的学习曲线：理解range-over-func提案需要花费大量时间，似乎在编写迭代器时使用该功能会很麻烦，但认为这是值得的，因为使用迭代器会更方便。
3. 新关键字：新的yield关键字对作者来说有些困惑和神奇，但认为自己可以学会使用。
4. 向后兼容性：将新的迭代器放在//go:build v1.23标签后面可能会很麻烦，并且根据消费者使用的 Go 版本，会呈现不同的库有效版本。

经验

1. 作者利用空闲时间尝试使用range-over-func，以 Kivik 库为例，升级到 Go 1.23rc1 后，很快适应并修改代码，实现了新的迭代器，证明学习编写range-over-func迭代器并不困难。
2. 作者创建了一个 PR，但旧版本的 Go 并没有开始编译失败，证明向后兼容性并非问题。
3. 作者编写了更多的测试用例，包括测试错误处理和break情况，经过修复后，最终的 PR 得以通过。
4. 总结经验：之前对range-over-func的担忧（如丑陋的接口名称、陡峭的学习曲线、新关键字、向后兼容性等）都被证明是夸大其词或不存在的，作者对range-over-func持积极态度，希望能废弃旧的迭代器实现。

因人而异

作者强调这只是自己的经验和结论，不同人可能有不同的体验和看法，欢迎大家分享自己的经验。如果想深入了解range-over-func的工作原理或教程，可以参考 Zach Musgrave 的帖子。