CC @griesemer @mdempsky

A random drive-by thought; instead of using just the alias name, use some combination of the alias name and the underlying defined type. Taking your example:

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

🚲 -shedding welcomed on the format.

Reason being, the error message is then clear that myByte is an alias (type myByte = byte) as opposed to a defined type (type myByte byte).

This is a known limitation of cmd/compile (and go/types), but I don't think we filed an issue, so thanks for that!

Within cmd/compile, the way we implement

type myByte = byte

is having the types.Sym for myByte simply defined to byte's OTYPE gc.Node. The corresponding types.Type, however, has no knowledge of the name "myByte".

There is a precedent within the compiler that uint8 and byte as well as int32 and rune (which are effectively aliases too) are actually represented as separate types.Type objects, and then at a few spots within the compiler we special case these two (e.g., eqtype for type identity).

Perhaps the easiest fix is to generalize those special cases to any kind of type aliases.

Another (perhaps obvious) observation in support of @bcmills's proposal is consistency with documentation:

package playground

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

type T = a.S

func Hello(s T) {
}

func Fail() {
	Hello(5)
}

fails to compile with the message:

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

But the godoc is:

func Hello(s T)

Change https://golang.org/cl/98476 mentions this issue: cmd/compile: prevent detection of wrong duplicates

I'm interested in this problem, so I'm thinking about it.

I agree this would be a "nice to have" but I don't think this is of particular high priority. I also think it's quite subtle to get right in general (requires complete understanding of type representation in compiler).

This came up in golang-nuts.