-
Notifications
You must be signed in to change notification settings - Fork 18k
proposal: reflect/v2: make Value uncomparable #18871
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
Comments
CL https://golang.org/cl/36018 mentions this issue. |
Make the documentation more explicit that it is not safe to directly compare Value. Get straight to the point on how to do it correctly. Updates #18871 Change-Id: I2aa3253f779636b2f72a1aae8c9bb45d3c32c902 Reviewed-on: https://go-review.googlesource.com/36018 Reviewed-by: Keith Randall <[email protected]>
Adding |
What @ianlancetaylor said. It would break things like collecting a set of |
Is that so bad? It's funny that you bring up reflect.Values in a map. That was exactly what someone tried doing the other day and it "seemed to work". However, I do agree that we probably can't do this in Go 1. |
A map is fine in some cases. (e.g. using it as a set of things to process, and ranging over it to get the reflect.Values back) Maybe worth a static analysis checker? |
In the subset of the Go corpus v0.01 that actually compiles, there are 33 instances of using Of these, 12 compare against the zero value Of the 21 incorrect comparisons, 5 compare reflect.Values derived from function values, which would not be comparable if converted to interface values first. I've attached the list of matches.
|
https://golang.org/pkg/reflect/#Value: Using == on two Values does not compare the underlying values they represent, but rather the contents of the Value structs. To compare two Values, compare the results of the Interface method. See also golang/go#18871
Change https://golang.org/cl/308209 mentions this issue: |
Comparing reflect.Values directly is almost certainly not what you want. That compares reflect's internal representation, not the underlying value it represents. One compares reflect.Values correctly by comparing the results of .Interface() calls. Fixes golang/go#43993 Update golang/go#18871 Change-Id: I6f441d920a5089bd346e5431032780403cefca76 Reviewed-on: https://go-review.googlesource.com/c/tools/+/308209 Trust: Keith Randall <[email protected]> Trust: Joe Tsai <[email protected]> Run-TryBot: Keith Randall <[email protected]> gopls-CI: kokoro <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Joe Tsai <[email protected]>
Comparing two
Value
type does not do what the user expects. The type is documented as such:However, it is still common to see users accidentally make this mistake. What's worse is that it "seems to work", giving a false sense of security.
This is because the
Value
struct contains aflag
field whose value may be different for eachValue
and is entirely an implementation detail of the reflect package.Perhaps we should add a uncomparable type to prevent this misuse:
\cc @ianlancetaylor
The text was updated successfully, but these errors were encountered: