Comment 1:

Labels changed: added repo-tools, release-none.

Update: the refactor/lexical half of this issue was fixed by https://go-review.googlesource.com/10800
(and refactor/lexical was deleted). The refactor/satisfies part remains.

@alandonovan Please comment on this issue if you still think this is useful and explain what kind of API you'd suggest. Otherwise, feel free to close it. Thanks.

Here's a straw-man go/types API that would let us evaluate whether a small change to the implementation would eliminate the refactor/satisfies package:

We add a new field, Satisfies [][2]Type, to the Info struct. If this field is non-nil (even if empty), the client is assumed to want the extra information. Each time we call operand.assignableTo(x, T) where T is an non-empty interface type, x.typ is not identical to T, and the call returns true, we append a pair (x.typ, T) to the Satisfies slice.

The only change to assignableTo would be within the case documented as "T is an interface type and x implements T". A pointer to the Satisfies slice would be passed in, with nil meaning "don't record the information" as in the case where assignableTo is called from the public AssignableTo function.

I guess I should prototype this myself.

@alandonovan Seems fine to me implementation-wise. But as described, this will only record pair combinations that appeared in the type-checked code. Is that sufficient?

Yes, that's sufficient. Users can already compute assignability for arbitrary pairs of types; what's missing is knowing which types' assignability mattered to a particular package.