ch1-4.md

[reusee]

不知道作者是否看过这个提案？
https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md

按照这个提案，泛型和错误处理等特性都会渐进地引入，例如 go2 草案里的 error values，已经合并入主线了（除了需要泛型的部分），无意外的话1.13就会包含这个 error values 草案的内容：
golang/go@37f8481#diff-c93f2f0db26f58ae432e8d8f1dc9bd73
golang/go@62f5e81#diff-c93f2f0db26f58ae432e8d8f1dc9bd73

所以并不会有一个"2.0"的版本然后包括所有go2草案的实现，而是现在就已经开始做了。go1和go2并不是界限分明的，所以“go1退出历史”这种说法是不准确的。

Go 2 transition 提案的最后一段说得很明白：

If the above process works as planned, then in an important sense there never will be a Go 2. Or, to put it a different way, we will slowly transition to new language and library features.

[chai2010]

确实有你说的这种情况。但是参考Linux/Chrome的版本，即使是平滑的过渡，Go1也不可能版本更新到Go1.100。
我个人的感觉，Go2会在某个时间点打破Go1的兼容性承诺，这个时刻是必须升级大版本的。

[reusee]

Go 2 transition 这个提案就是讲如何处理不兼容的语言或者标准库的改动的。

1.12 的 go.mod 已经引入了语言版本的标记，就是 "go 1.xx" 这一行，标明这个模块最低的版本要求。不同的模块，可以使用不同的语言版本去编译，所以并不会有“打破Go1的兼容性承诺”出现。Background 这一段也明说了

Among the goals for the Go 2 process is to consider changes to the language and standard libraries that will break the guarantee. Since Go is used in a distributed open source environment, we cannot rely on a flag day. We must permit the interoperation of different packages written using different versions of Go.

所以就算版本是 2.x 3.x，现有的代码是不需要改动的，也可以和使用了新版本的特性或者语义的模块一起使用，毕竟“不兼容”只是在语法语义层面，到了中间代码就没有区别了。就好像 C/C++ 也有各种标准，编译器用 --std 区分不同的标准，但编译出来的目标文件是可以链接的。go 编译器也会一直支持旧的语言版本，所以升大版本不是必需的，小版本也可能引入改动，但怎么改，都有办法兼容使用了新旧语言版本的模块。

[chai2010]

毕竟“不兼容”只是在语法语义层面

如果语法层面出现了不兼容（比如中文函数名被改为导出了），那么就是破坏了Go1的承诺。
至于说中间代码层面兼容，目前的Go语言还没有一个ABI标准，更是奢望了，Go1诺言也没有涉及这个层面。

至于“go1退出历史”这种说法，这是我的个人观点，如果不认同可以忽略啊

[reusee]

就你这个例子，按照这个提案的做法，在同一个程序里，可以是新模块用新的导出规则，旧模块用旧的导出规则，并不会破坏go1兼容性。这个提案的初衷就是让新旧语言可以共存于一个程序里，而不是一刀切开。go1的兼容性承诺是旧代码不会被break，这个提案目的就是不论语言怎么改，旧代码都不用改。

对于 ABI，也有相关的提案：https://github.com/golang/proposal/blob/master/design/27539-internal-abi.md
和源码层面的兼容类似，这个提案也是要实现新旧 ABI 的兼容。现在的 ABI 是有事实标准的，而且将会被称为 ABI0。后续所有 ABI 层面的改进，都不会破坏对 ABI0 的兼容。一个程序某些模块遵循旧 ABI 写汇编，另外一些模块遵循新 ABI，是允许的。

这些都是逐渐演进的过程，没有什么改朝换代，这和其他语言的发展方式是不一样的。

[chai2010]

并不会破坏go1兼容性

这只是大家的愿望，我也希望这样，但是我觉得很难做到（之前的某个版本好像就发生过Go1承诺被打破的事情）。

即使退一步，Go1真的是Go2的完美子集，但是我个人还是愿意将这个子集当作是Go2的新特性。
类比，当一个C程序重新命名为a.cpp的时候，它就已经是C++语言的。

[reusee]

https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md#language-removals

这一段就是讲删除一个语言特性之后，仍然保证旧代码可以继续使用。很显然，新版本删除了某个语言特性，那旧版本语言就不可能是新版本语言的子集。旧代码可以继续使用，那就是兼容了，所以兼容并不代表旧版本必须是新版本的子集。

[chai2010]

我建议你可以尝试去官方提个Issue，去掉标题中Go2的说法（换成go1.20什么的），毕竟这样容易引起歧义。

[reusee]

确实啊，Go 2 transition 提案最后一段，就是这个意思。go 2 这个名称确实会给人一种不兼容的新语言的感觉，但实际不会不兼容，这只是一种泛指。特性会逐渐加，就像 error values 大概率加到 1.13，那 1.13 是否应该改叫 2.0 呢？它都实现了部分 go 2 draft 里的东西了。

所以你认为 2020 才开始 go2 开发是不对的，已经开始开发了。go1 的支持也不会在 2030 终止，编译器会一直支持现有的代码。

[choleraehyq]

并不会破坏go1兼容性

这只是大家的愿望，我也希望这样，但是我觉得很难做到（之前的某个版本好像就发生过Go1承诺被打破的事情）。

即使退一步，Go1真的是Go2的完美子集，但是我个人还是愿意将这个子集当作是Go2的新特性。
类比，当一个C程序重新命名为a.cpp的时候，它就已经是C++语言的。

啥版本发生过 break go 1 promise 的事呢