背景：在https://go.dev/cl/559435中API检查失败。
o2g1uqev1#
我认为这可能不是API检查器中的一个bug。实际上，这可能是我们能否移动类型的问题。假设包a有一个类型T。那么如果我们执行fmt.Printf("%v\n", reflect.ValueOf(a.T{}).Type()),它会打印a.T。然后如果我们将T移动到包b并用type T = b.T替换a中T的声明，那么相同的打印语句现在将打印b.T。因此，这种移动不会被调用者检测不到。
a
T
fmt.Printf("%v\n", reflect.ValueOf(a.T{}).Type())
a.T
b
type T = b.T
b.T
zbq4xfa02#
@qiulaidongfeng
k4emjkb13#
我认为这实际上可能是一个关于我们是否可以移动类型的问题。如果我们执行fmt.Printf("%v ", reflect.ValueOf(a.T{}).Type()),它会打印出a.T。然后，如果我们将T移动到包b并用类型T = b.T替换a中的T声明，那么相同的打印语句现在将打印出b.T。参考链接：https://go.dev/doc/go1compat ,兼容性是源代码级别的。参考链接：https://go.dev/blog/compat ,关于兼容性最清楚的事实是我们不能剥夺API,否则使用它的程序将出现问题。根据上述关于兼容性的博客，我无法判断fmt.Printf("%v ", reflect.ValueOf(a.T{}).Type())输出的a.T向后兼容性是否保证不会改变？
fmt.Printf("%v ", reflect.ValueOf(a.T{}).Type())
fzwojiic4#
@randall77 在我看来，显式别名类型节点应该允许我们解决这个问题：也就是说，如果 package a; type T = b.T ,打印一个 a.T 值仍然可以打印 a.T 。但我没有仔细考虑过。
package a; type T = b.T
话虽如此，根据原始别名提案，我们已经遇到了关于反射(链接)的问题。此外，在文档中似乎我们没有提到别名类型的反射名称(不仅仅是匿名字段名称)-可能是疏忽。无论如何，我认为我们不必要求使用反向兼容性保证时保持不变的反射类型名称。
u2nhd7ah5#
将文本内容翻译为中文：移动到1.24。不紧急。
5条答案
按热度按时间o2g1uqev1#
我认为这可能不是API检查器中的一个bug。实际上，这可能是我们能否移动类型的问题。
假设包
a有一个类型T。那么如果我们执行
fmt.Printf("%v\n", reflect.ValueOf(a.T{}).Type()),它会打印a.T。然后如果我们将
T移动到包b并用type T = b.T替换a中T的声明，那么相同的打印语句现在将打印b.T。因此，这种移动不会被调用者检测不到。
zbq4xfa02#
@qiulaidongfeng
k4emjkb13#
我认为这实际上可能是一个关于我们是否可以移动类型的问题。
如果我们执行
fmt.Printf("%v ", reflect.ValueOf(a.T{}).Type()),它会打印出a.T。然后，如果我们将T移动到包b并用类型T = b.T替换a中的T声明，那么相同的打印语句现在将打印出b.T。
参考链接：https://go.dev/doc/go1compat ,兼容性是源代码级别的。
参考链接：https://go.dev/blog/compat ,关于兼容性最清楚的事实是我们不能剥夺API,否则使用它的程序将出现问题。
根据上述关于兼容性的博客，我无法判断
fmt.Printf("%v ", reflect.ValueOf(a.T{}).Type())输出的a.T向后兼容性是否保证不会改变？fzwojiic4#
@randall77 在我看来，显式别名类型节点应该允许我们解决这个问题：也就是说，如果
package a; type T = b.T,打印一个a.T值仍然可以打印a.T。但我没有仔细考虑过。话虽如此，根据原始别名提案，我们已经遇到了关于反射(链接)的问题。此外，在文档中似乎我们没有提到别名类型的反射名称(不仅仅是匿名字段名称)-可能是疏忽。无论如何，我认为我们不必要求使用反向兼容性保证时保持不变的反射类型名称。
u2nhd7ah5#
将文本内容翻译为中文：移动到1.24。不紧急。