proposal: go/types: add HasTypeName interface

[adonovan]

During the types.Alias work, there was a recurring need (7 times in x/tools; @findleyr is adding an eighth) for this interface:

package types // import "go/types"

// HasTypeName abstracts the three kinds of types that have declared names:
// aliases ([*Alias]), defined types ([*Named]), and type parameters ([*TypeParam]).
//
// Note that the Go spec considers built-in types such as string and int to
// be defined types, but this package represents them as [*Basic],
// since they do not have a declaration or [TypeName].
type HasTypeName interface {
    Obj() *TypeName
}

Of course users can easily define it for themselves, but adding it to go/types provides a good place to hang additional documentation.

Related:

• go/types: document that Underlying affects Named, Alias, TypeParam #65774

@findleyr @griesemer

[gopherbot]

Change https://go.dev/cl/604476 mentions this issue: go/types: clarify Named, Alias, TypeName, Object

[griesemer]

I note that we have an unexported function

// hasName reports whether t has a name. This includes
// predeclared types, defined types, and type parameters.
// hasName may be called with types that are not fully set up.
func hasName(t Type) bool {
	switch Unalias(t).(type) {
	case *Basic, *Named, *TypeParam:
		return true
	}
	return false
}

Per the spec: "Predeclared types, defined types, and type parameters are called named types."

Maybe the interface should just be called "HasName". Having theObj method is not quite the same as being a named type (aliases have Obj but may denote type literals - one of the mistakes we made when introducing aliases).

[adonovan]

In the branch where I was playing with this I ended up using the name TypeWithName to make clear that the interface is a restriction of Type; otherwise it's a bit unclear what kind of thing it is.

[findleyr]

My 2 cents: types.HasName seems better than types.TypeWithName

[griesemer]

In the spec, a named type has a very specific meaning; specifically, an alias type may not be a named type. This interface is about whether a type has an Obj method which returns a TypeName. I think HasTypeName or HasObj seem ok names.

[aclements]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— aclements for the proposal review group

[aclements]

@griesemer notes that this is almost but not quite a "named type" from the spec (an alias is only a named type if it aliases a named type). We'll need to rewrite the comment to be careful about that. The fact that it doesn't correspond exactly to the spec seems to be okay. Given that, HasTypeName is good.

[aclements]

@adonovan to post an updated version that accounts for #71886 (but the API will stay the same)

[aclements]

Based on the discussion above, this proposal seems like a likely accept.
— aclements for the proposal review group

The proposal is to add the following to package go/types:

// HasTypeName abstracts the four kinds of types that have declared names:
// basic types ([*Basic]), defined types ([*Named]), aliases ([*Alias]), and
// type parameters ([*TypeParam]),
//
// Note that the Go spec considers all of these "named types", with the exception
// of alias types, which are only "named types" if their target is a named type.
type HasTypeName interface {
    Obj() *TypeName
}

[adonovan]

Unfortunately I just discovered that #71886 is infeasible, so we need to revert the comment to the original wording to exclude *Basic.

[griesemer]

Maybe this should be a function instead?

func TypeNameFor(Type) *TypeName

[aclements]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— aclements for the proposal review group

[adonovan]

Maybe this should be a function instead?
func TypeNameFor(Type) *TypeName

Yeah, that would work. I looked at x/tools and 5 out of 7 of the places where we define this interface would be satisfied with this helper.

[gopherbot]

Change https://go.dev/cl/672975 mentions this issue: internal/typesinternal: add TypeNameFor helper

[adonovan]

I added func TypeNameFor(Type) *TypeName to gopls, shown below, but I don't think it's a simple enough abstraction to go in go/types. So I retract this proposal too.

// TypeNameFor returns the type name symbol for the specified type, if
// it is a [*types.Alias], [*types.Named], [*types.TypeParam], or a
// [*types.Basic] representing a type.
//
// For all other types, and for Basic types representing a builtin,
// constant, or nil, it returns nil. Be careful not to convert the
// resulting nil pointer to a [types.Object]!
//
// If t is the type of a constant, it may be an "untyped" type, which
// has no TypeName. To access the name of such types (e.g. "untyped
// int"), use [types.Basic.Name].
func TypeNameFor(t types.Type) *types.TypeName {
	switch t := t.(type) {
	case *types.Alias:
		return t.Obj()
	case *types.Named:
		return t.Obj()
	case *types.TypeParam:
		return t.Obj()
	case *types.Basic:
		// See issues #71886 and #66890 for some history.
		if tname, ok := types.Universe.Lookup(t.Name()).(*types.TypeName); ok {
			return tname
		}
	}
	return nil
}

[aclements]

This proposal has been declined as retracted.
— aclements for the proposal review group