cmd/compile: aliases should not apply to unnamed types

[davecheney]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version devel +08a3a7c Thu Feb 2 02:14:50 2017 +0000 linux/amd64

What operating system and processor architecture are you using (go env)?

linux/amd64

What did you do?

package main

import (
        "fmt"
        "q"
)

func main() {
        var a q.A
        var b q.B // i'm a named unnamed type !!!

        fmt.Printf("%T\t%T\n", a, b)
}

What did you expect to see?

deadwood(~/src) % go run main.go
q.A     q.B

What did you see instead?

deadwood(~/src) % go run main.go
q.A     []int

Discussion

Aliases shouldn't not apply to unnamed type. Their is no "code repair" story in moving from one unnamed type to another. Allowing aliases on unnamed types means I can no longer teach Go as simply named and unnamed types. Instead I have to say

oh, unless it's an alias, in which case you have to remember that it could be an unnamed type, even when you import to from another package.

And worse, it will enable people to promulgate readability anti patterns like

type Any = interface{}

Please do not allow unnamed types to be aliased.

[griesemer]

I'm going to close this because this is not a bug report. The current implementation follows the design document https://github.com/golang/proposal/blob/master/design/18130-type-alias.md exactly and thus is working as intended.

There may be an issue with the design, but the right place to discuss that is with #18130 . The proposal has been discussed at length and so has the design document which outlines this exact behavior and the need for possible spec changes in detail.