go/types: add LookupSelection function

[adonovan]

Background: The type checker has two different APIs for the same concept, namely information about a selection of a field or method:

• Info.Selections and MethodSet both use the record type Selection;
• LookupFieldOrMethod returns a triple, (obj, indices, indirect).

There is no way to construct a Selection from the result of LookupFieldOrMethod. Especially when operating in parallel on the method sets of two types, it is a perennial nuisance that these corresponding items have different forms.

Proposal: We propose a function, Select, to bridge this gap.

package types

// Select selects the field or method whose ID is Id(pkg, name), on a value of type recv.
// See LookupFieldOrMethod for more detail.
func Select(recv Type, addressable bool, pkg *Package, name string) (Selection, bool) {
	obj, index, indirect := LookupFieldOrMethod(recv, addressable, pkg, name string)
	var kind SelectionKind 
	switch obj {
	case *types.Func:
		kind = MethodVal
	case *types.Var:
		kind = FieldVal
	}
	return Selection{kind, recv, obj, index, indirect}, obj != nil
}

Related:

• go/types: API: rename LookupFieldOrMethod to Select (or something select-y) #10091: Closed because it was a rename; this issue proposes an addition.
• go/types: request for NewSelection constructor #12881: superseded by this issue. Also, we have never observed a need for NewSelection other than the one above.

@findleyr @griesemer @timothy-king

[gabyhelp]

Related Issues

• go/types: API: rename LookupFieldOrMethod to Select (or something select-y) #10091 (closed)
• go/types: request for NewSelection constructor #12881

Related Documentation

• Package types > type Selection ¶ 1.5

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[griesemer]

What is the problem with defining this (rather small) function external to go/types?

[adonovan]

The expression Selection{...} cannot be written outside the package.

[griesemer]

Some questions:

1. Should this just be a simple constructor instead, as in

func MakeSelection(kind SelectionKind, recvType, obj Object, index []int,	indirect bool) Selection

which would provide max. flexibility; or, if not
2) What about the SelectionKind of MethodExpr
and, if we stick with the proposal
3) Why return a bool instead of an zero Selection, or just look for the nil Object?

[adonovan]

1. That would be maximally flexible, but I've never once needed MakeSelection other than as part of the Select operation, and the Select operation seems tidier to me.

2. I updated the doc comment for Select to make explicit that it is about selections on a value (x.f) not on a type (T.f), so only the *Value kinds are possible; MethodExpr isn't needed.

3. The zero selection has Kind of FieldVal, since we forgot to reserve the zero value for InvalidSelection. Having to remember that FieldVal doesn't imply Obj() != nil seems error-prone. A boolean makes it obvious.

[rsc]

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

[griesemer]

Let's implement this and see how it works out inside the type checker. If we can use Select everywhere (or almost everywhere) that would be a good validation of the API. If not, it may tell us how to tweak it.

[gopherbot]

Change https://go.dev/cl/647196 mentions this issue: go/types: Select: returns LookupFieldOrMethod as a Selection

[aclements]

Let's implement this and see how it works out inside the type checker.

Sounds good.

Minor bikeshedding: "select" may be a confusing name given that this is unrelated to the select statement. But it's probably fine.

[aclements]

There's a CL that implements this and uses it in the type checker and it seems reasonable.