如何评价可能在 Go 1.8 加入的 alias 语法？

提案最终被他们自己reverted了，好像是史上第一次回滚已经接受的提案：

Revert "spec: add new language for alias declarations" · golang/go@87f4e36 · GitHub

不是因为社区反对，而是因为搬石头砸到自己脚了，提案有未定义行为。

跟我

如何评价 Go 语言即将推出的官方包管理工具方案？ - 布丁的回答

的回答一样，不管是 Google 内部还是开源社区，Go 的流行容易带来肤浅短视的功能，这个困境几乎是必然的。

说回 alias 提案，Google 自己的代码管理系统上没有alias也还是可以做这种超大重构的 (

Why Google Stores Billions of Lines of Code in a Single Repository

), go types, go fix 也就该是在这种场景下用的，虽然会难搞很多（要发个一次过改成千上万个文件的改动，而且自动工具有可能漏网，因为有的代码生成的软件本身可能查不出这个pattern）但长痛不如短痛。而开源社区的反馈是应该用依赖的 versioning 管理避免这样的重构，然而这迟早会遇到间接依赖同一个包接口不兼容的两个版本的问题，而且就算做 vendoring 也不见得能解决。跟我在上面的回答一样，这两个事件，两种方向，反映的都是同一个更深层次的软件工程问题。