I look for other similar examples in the standard library and came up with unicode.MaxCase. That's the only maximum-element name I could find but I could easily have missed one. There are other iota cases with no maximum element, such as ast.ObjKind (https://golang.org/pkg/go/ast/#ObjKind).

It might be okay to add reflect.MaxKind, but we'd have to be clear about the fact that the numeric value could change in future versions of Go. In general we've avoided doing that, because it breaks code that assumes that, say, [3]int and [MaxKind]int are the same type if MaxKind changes from 3 to 4.

/cc @robpike

Any other thoughts about adding reflect.MaxKind, a constant value which may change over time?

Code that depends on Kind is likely to have to change if any Kinds are added, so the changing value of MaxKind would be a minor consideration. Not sure if that's an argument for or against the constant, but speaking off the cuff, I'd say against: long-term stability of this list isn't guaranteed, and a programmer that depends on the list must pay attention. MaxKind doesn't help much.

To put it another way, if a programmer depended only on MaxKind, there could be surprises as new elements arise with intermediate values that are not covered by the code, while there is a chance that code that depends on UnsafePointer at the end of the list, with unchanging value, might continue to work by ignoring the extra values; the subset is consistent. But of course breakage is possible either way.

To reiterate, I am not convinced but leaning "no".

I agree that the original case, making a histogram indexed by kind, certainly would benefit from MaxKind. What else would? I suppose any kind of map[reflect.Kind]T could be replaced with [reflect.MaxKind]T, which would be more efficient. But when else do you want to make a map keyed by kind? New Kinds also don't happen very often, which cuts both ways. I'm trying to understand how often this will really come up. We have other enumerations like in go/token that haven't needed max either.

This does seem like it has limited utility. Based on the discussion above and the lack of new use cases in response to the last comment, this seems like a likely decline.

No change in consensus, so declined.