On Go tip, (*types2.Named).Obj() now returns t.orig.obj. For an instantiated type, this is the TypeName associated with the base type, not the TypeName representing the instantiated type.

@findleyr was saying that it didn't necessarily make sense to expose the instantiated type, since the instantiated type is de-duplicated, so there is no way to associate a fixed position with the instantiated type. But, as he mentioned, maybe it should just have an nil position or a special marker for an undefined position?

In any case, in the compiler, it would be convenient to be able to access t.obj, even if the position is not set. So, maybe we can have a t.InstanceObj() just for the compiler (not the external API)? If we restructured some code in the types2-to-types1 conversion, we could probably deal with objects in some cases and types in other cases, and wouldn't necessarily need t.InstanceObj(). But it is definitely would make things easier in the current code. In particular, we would be able to access the methods of the instantiated type in some cases, rather than having to do our own type substitution.

So, this is a discussion bug (as to whether InstanceObj() may make sense for the external API or not), and/or just a request for the compiler. This can be lower priority, since we are already doing without InstanceObj in the compiler (by doing the extra type substitution where needed in (*noder.irgen).fillinMethods).

@findleyr @griesemer