btw, should struct{t} and struct{T} be viewed as the same type?

The following program print the same output for the two types:

package main

import "fmt"
import "time"
import "reflect"

type t = time.Time
type T = time.Time

type A = struct{t}
type B = struct{T}

func main() {
	t := reflect.TypeOf(A{}) // the Singer type
	fmt.Println(t, "has", t.NumField(), "fields:")
	for i := 0; i < t.NumField(); i++ {
		fmt.Print("   filed#", i, ": ", t.Field(i).Name, "\n")
	}
	
	/*
	struct { time.Time } has 1 fields:
	filed#0: t
	*/
	
	t = reflect.TypeOf(B{}) // the Singer type
	fmt.Println(t, "has", t.NumField(), "fields:")
	for i := 0; i < t.NumField(); i++ {
		fmt.Print("   filed#", i, ": ", t.Field(i).Name, "\n")
	}
	
	/*
	struct { time.Time } has 1 fields:
	filed#0: t
	*/
}

I feel the outputs are wrong, at least the outputs should be filed#0: Time.

But I change the type A and B to non-alias types, then the outputs will be different
(I think the outputs are correct):

main.A has 1 fields:
   filed#0: t
main.B has 1 fields:
   filed#0: T

A simpler repro does not require separate packages: https://play.golang.org/p/_ZimDvvVU0u

The compiler is correct to emit an error, because the fields of the two struct types have different names (t and T, respectively).
The fact that the error does not include the correct field names is a bug.

The fix is presumably to use the name of the field in the error message instead of the name of the underlying type.

(CC @griesemer, maybe?)

If the error messages are correct, the problem is bigger:

package main

import (
	"fmt"
	"time"
)

type t = time.Time
type T = time.Time

type A = struct{ t }
type B = struct{ T }

func main() {
	var a A
	var b B
	fmt.Println(interface{}(b) == interface{}(a)) // true
	//fmt.Println(b == a)
}

Huh, that's a neat bug you've found!
(https://play.golang.org/p/LSwVZ_aoNmc)

reduced further https://play.golang.org/p/m6Wv1Hk1U8h

1. Two struct types with differently named (corresponding) embedded fields are different types, even if the embedded field types are identical. So the assignments a = b are expected to be reported as invalid at compile time.

2. Because of 1), runtime interface comparison of a and b values should return false, but the issue is that (basically) the same printing code that's used in the error message (and which prints both types as struct{ int }) is used to identify those types' symbols, so the type information is incorrect.

Too late for 1.12.

@bcmills they are not totally the same. The unequalness in this issue is because the field names are different.

This issue is currently labeled as early-in-cycle for Go 1.15. That time is now, so friendly ping. If it no longer needs to be done early in cycle, that label can be removed.

One more difference between gc and gccgo:

package main

import "time"

type T = struct {
	time.Time
}

func main() {
	println(T.Add)
}

It compiles ok with gc, but not gccgo.

As the line fmt.Printf("%T\n", struct {time.Time}.Add) also fails to compile with gccgo. I created a new issue for gccgo.

This issue is currently labeled as early-in-cycle for Go 1.16.
That time is now, so this is a friendly ping so the issue is looked at again.

This didn't make it for Go 1.16. Should try to address for Go 1.17, certainly for 1.18. As already explained we need to fix the printing of structs, both for error messages (to make clear what's wrong), and for generating type descriptors.

Probably not too hard to do but the respective code is in fmt.go which is mess. Getting it right is subtle. Not worth the risk for 1.16. Eventually we will need to get rid of this code.

For reference: go/types and types2 report for the last line of https://play.golang.org/p/m6Wv1Hk1U8h:

main.go:14:14: invalid operation: cannot compare a == b (mismatched types struct{int} and struct{T /* = int */})

This issue is currently labeled as early-in-cycle for Go 1.17.
That time is now, so a friendly reminder to look at it again.

Again, given other priorities, this didn't make it for 1.17. Pushing to 1.18.

This issue is currently labeled as early-in-cycle for Go 1.18.
That time is now, so this is a friendly ping so the issue is looked at again.

@griesemer I assume that we should push this to 1.19?

Moved to 1.19.

It looks this bug has been fixed in https://golang.org/cl/378434, for #50190.

@mdempsky Is there anything left to do here?

@dotaheor Thanks for pointing that out.

@griesemer I don't think so. I looked over the failure cases, and I don't think they add anything significant beyond ones we already added for #50190. Closing.