CC @griesemer@mdempsky

随机驾驶思考；不要只使用别名名称，而是使用别名名称和底层定义类型的组合。以你的例子为例：

foo.go:4:5: error: incompatible type in initialization (cannot use type string as type myByte (-> byte))

🚲 -欢迎在格式上脱落。
原因在于，错误信息随后变得清晰，即 myByte 是别名( type myByte = byte )而不是定义类型( type myByte byte )。

这是一个已知的cmd/compile(和go/types)的限制，但我认为我们没有提交一个问题，所以感谢！
在cmd/compile中，我们实现

type myByte = byte

的方式是将myByte简单地定义为byte的OTYPE gc.Node。然而，相应的types.Type并不知道“myByte”这个名字。
编译器中有一个先例，即uint8、byte以及int32和rune(实际上也是别名)实际上被表示为单独的types.Type对象，然后在编译器的几个地方我们对这两个特殊情况进行了特殊处理(例如，类型身份的eqtype)。
也许最简单的修复方法是将这些特殊情况泛化为任何类型的类型别名。

另一个(可能明显的)支持@bcmills提议的观察是与文档的一致性：

package playground

import (
	"github.com/myitcv/playground/internal/a"
)

type T = a.S

func Hello(s T) {
}

func Fail() {
	Hello(5)
}

在编译时出现错误信息：

# github.com/myitcv/playground
./playground.go:13:8: cannot use 5 (type int) as type a.S in argument to Hello

但是 godoc 是：

func Hello(s T)

https://golang.org/cl/98476提到了这个问题：cmd/compile: prevent detection of wrong duplicates

我对这个问题很感兴趣，所以我在思考。

我同意这是一个"锦上添花"的功能，但我认为它并不是特别重要的优先事项。我也认为在一般情况下正确实现它是相当微妙的(需要完全理解编译器中的类型表示)。

这出现在golang-nuts中。