I'm not sure if this could be considered a bug or not, but it's unfortunate behavior for certain patterns of type analysis. The problem is with a type like:
type X time.Time When you inspect type X, you find that it is analyzed as a types.Named. Its immediate underlying type is a types.Struct. I have a few problems with this: - This hides the fact that there is more information about type X available (time.Time's documentation) - This makes the location and identity of the actual struct definition hard to find because the types.Struct is not an object that you can find the source position of - The dependency relationship between these types is not obvious (as in, changing/renaming time.Time will affect the program using X, but not the other way around) Here's a small demo of the situation described here: https://play.golang.org/p/oqYRDIO7kmf Please let me know if I'm something missing, but as it stands, I think the only way around these issues would be to analyze the syntax of every defined type to check if it's got an underlying name or not. Does this sound like something that could be safely improved within go/types? Thanks, Stephen -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b678cb60-8871-43a1-acda-544bb1e78b99%40googlegroups.com.
