Also more code that will Just Work when we add int128.

(crosses fingers)

Counter proposal: Perhaps we should add accessor methods on reflect.Kind instead? I feel like reflect.Value has enough methods.

func (k reflect.Kind) IsInt()
func (k reflect.Kind) IsUint()
func (k reflect.Kind) IsFloat()
func (k reflect.Kind) IsComplex()

@cespare, if int128 is added, we can't make Value.Int start returning int128 instead of int64, so making CanInt report true for int128 would be misleading. Likewise, @dsnet, those are fine, but would misleading/insufficient if int128 were added. I think CanX paired with X is more explicit and matches Addr/CanAddr and Interface/CanInterface.

How about a new type for representing a set of Kinds? Something like...

type Kinds uint

// Has return true when k is a member of Kinds, false otherwise.
func (s Kinds) Has(k reflect.Kind) bool {
	return (1<<k)&s != 0
}

const (
	Int64Kinds  Kinds = 1<<reflect.Int | 1<<reflect.Int8 | 1<<reflect.Int16 | 1<<reflect.Int32 | 1<<reflect.Int64
	Uint64Kinds Kinds = 1<<reflect.Uint | 1<<reflect.Uint8 | 1<<reflect.Uint16 | 1<<reflect.Uint32 | 1<<reflect.Uint64 | 1<<reflect.Uintptr
)

If new types get added, just need to add new constants.

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

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

I still prefer methods declared on reflect.Kind rather than reflect.Value since it's seems broadly more useful. There are times where I have a reflect.Kind on hand and I also do logic similar to:

case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64:

Having methods be declared on reflect.Value unfortunately doesn't help these cases.

In the (unlikely? likely?) future where we have int128, Kind.IsInt() would probably return true, but Value.CanInt() would probably return false. It seems like we need the more precise Value.CanInt in this case for deciding whether we are able to call Value.Int.

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

Change https://golang.org/cl/352131 mentions this issue: reflect: add Value.{CanInt, CanUint, CanFloat, CanComplex}