Thanks for the response. I understand that what I'm asking is a bit beyond the scope of what a *compiler* would need to correctly implement the language, which is what the spec details. The question/request here is more about usability of the types package for purposes that are more human/developer-driven, like documentation and static analysis. For purposes like these, having some way to associate the types would be helpful, because while there is no "direct" connection that the compiler would care about, there is absolutely an "indirect" connection that humans or other tools may care about.
The fact that the types are not hierarchically related actually underscores why this matters. Picking on time.Time still: one might create a new type based on time.Time to handle a detail like (un)marshaling to the *correct* time.Location, given that such information is not conveyed by any of the formats supported by the time package <https://github.com/golang/go/issues/28421>. Making it easy to see that such a type is underlied by time.Time would make it easier for tools to, say, identify that this code should be checked for correctness with regard to timezones. I could imagine other use cases of this kind of association in things like security scanning or searching for usage of possible PII (for GDPR/privacy compliance). The only way I see is to accomplish this right now is to inspect the AST. It's surprisingly complicated and feels a little silly because I'd bet I'm repeating work that the types package (and friends) already did. Here's implementing such a lookup for my toy example: https://play.golang.org/p/Ph7YV0a8JU4. Is there something I'm missing that could make this simpler? Thinking about possible solutions, changing the behavior of the types.Named.Underlying() method seems like the naive approach. I would guess that returning an underlying types.Named would be considered a breaking change. It wouldn't change the method signature, but it would break code that currently assumes the value returned there is a more concrete type. Adding a method like func (Named) UnderlyingName() *Named could work, but I also see some downsides of that approach, like that it proliferates API in an already complex package. Adding something to types.Info might be the most reasonable option, to reduce the impact of such an addition. Thanks again, Stephen On Wednesday, November 20, 2019 at 6:27:19 AM UTC-5, Max wrote: > > Addendum: > > this may be surprising from the point of view of object-oriented > programming, class inheritance etc. > but at risk of stating the obvious, in Go there is no class inheritance: > type X time.Time > > creates a new type X that is (almost) completely unrelated to time.Time: > 1. the new type X does not have the methods of time.Time, > 2. and X cannot be used interchangeably with time.Time. > > So it makes sense that `types.Type` does not provide any information to > link them. > > the only connection is their identical underlying type, which allows to > *explicitly* convert between them, i.e. the following works: > var x X > var t time.Time = time.Time(x) > var x2 X = X(t) > > > > On Wednesday, November 20, 2019 at 12:18:28 PM UTC+1, Max wrote: >> >> >> It's part of the language specifications >> https://golang.org/ref/spec#Types. It says: >> type ( >> B1 string >> B2 B1 >> ) >> >> "The underlying type of [...] B1 and B2 is string" >> >> In other words, when you write >> type X time.Time >> there is absolutely *no direct* connection between the types X and >> time.Time: >> the only connection is that they both have the same *underlying* type, >> which is some unnamed struct, as you wrote. >> > -- 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/8924992e-b19c-43e1-97be-05e5e27a3949%40googlegroups.com.
