On further thought I suspect the problem is AssignableTo doesn't know the constant's value. If it were to return true in this case then there would be false positives due to integer sign mismatch and overflow.

Taking a step back, I'm trying to make gopls (the x/tools LSP implementation) be smarter when suggesting untyped constants as completion candidates (i.e. it should only suggest a constant if it is assignable to the expected type at the cursor). In other words, I want to determine if a given *types.Const is assignable to a given types.Type. It looks like the AssignableTo code path would do the right thing if there was a way to set the operand's "val".

I agree it that the go/types behavior deserves at least a closer look in this case.

@muirrn Indeed, AssignableTo doesn't know about the untyped int value in this case. That said, returning false is also not very satisfactory; it should probably return some error (or panic) - but we can't change that.

Barring adding another entry point to the API, I don't know what else can be done here, but I leave this open (with reframed title) as a reminder to review the code path (and document it better).

Thanks, sounds reasonable.

For others' future reference, to prefer false positives over false negatives I did something like https://play.golang.org/p/1G9aEFaLenH

@griesemer Possibly related, the below prints true when I expect false:

fmt.Println(types.AssignableTo(
	types.Typ[types.UntypedFloat],
	types.Typ[types.Int],
))

This seems to be causing some false positive completion candidates in gopls since gopls thinks an untyped float constant is assignable to an int variable.

Edit: this was using Go 1.16.2.

/cc @findleyr