-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
reflect: add Value.CanInt, CanUint, CanFloat #47658
Comments
Also more code that will Just Work when we add (crosses fingers) |
Counter proposal: Perhaps we should add accessor methods on func (k reflect.Kind) IsInt()
func (k reflect.Kind) IsUint()
func (k reflect.Kind) IsFloat()
func (k reflect.Kind) IsComplex() |
@cespare, if |
How about a new type for representing a set of Kinds? Something like...
If new types get added, just need to add new constants. |
This proposal has been added to the active column of the proposals project |
Based on the discussion above, this proposal seems like a likely accept. |
I still prefer methods declared on
Having methods be declared on |
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. 🎉 |
Change https://golang.org/cl/352131 mentions this issue: |
reflect already has:
Those latter three are tedious to use because you need to write:
I've used up my life quota of typing
reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64
(and always forgettingreflect.Uintptr
in the corresponding usually-copy-pasteduint
set) and would now prefer to write the proposedCanFoo
bool methods:Oh, and might as well add CanComplex too for consistency.
The text was updated successfully, but these errors were encountered: