At first I thought it was due to an implicit type conversion and they weren't technically assignable, but in the spec assignability seems to include implicit conversions, at least for non-constant values. For untyped constants in particular it says an untyped constant x is assignable to type T if x is in the set of values determined by T.. I'm not sure exactly what that means or if it disqualifies this case. In general since the untyped constant is assignable to the named type, I assumed the AssignableTo function would agree.
Also note that reflect.Type.AssignableTo behaves consistently with types.AssignableTo.
/cc @griesemer since you are primary owner of go/types
The text was updated successfully, but these errors were encountered:
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".
@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).