/cc @mdempsky

It's not a common mistake: local types are rare, and local types named like outer types are even more rare, so I'd say there's no urgency on this.

That said, if we just say something like "type T (defined in F)" we could provide a very accurate message. Shouldn't be hard to do. It's a bit of a balance between precision of error and overly verbose error message.

It's also possible (albeit increasingly unlikely) for multiple type Ts to be declared within a single function, so there may be cases where we want to disambiguate identically named types by line number instead: https://play.golang.org/p/zs6_-3awLP

@mdempsky Indeed. It probably would be better to just report the line number (or file:line info). Needs a bit of experimentation for a pleasant result.

CL https://golang.org/cl/42750 mentions this issue.

CL 42750 adds support for line number disambiguation when using two different-but-identical-looking named types, but there are also cases where we have different-but-identical-looking anonymous types. For example:

func _() {
    var s []int
    type int uint
    var t []int = s
    _ = t
}

currently emits:

cannot use s (type []int) as type []int in assignment

And in general, there might be arbitrarily many different named types within the source and destination types (e.g., maps and structs)

Are we happy to only special case named types? Or any ideas how to explain to the user why "map[K]V" and "map[K]V" might be different types?

I didn't think about that. It seems less likely to occur, but I don't like the inconsistency. Happy to abandon the CL.

Not urgent. Moving to 1.10.