reflect: add a range like interface for Value #11104
Comments
|
reflect.Value already allows efficient emulation of range semantics for arrays, slices, strings, and channels, so a fully generic range-like operation is unnecessary. It need only work for maps. There's an argument for making it generic for consistency's sake, but I think it's pretty weak. For arrays, slices, and channels, range is only syntactic sugar, which doesn't provide the same value in reflect. Even if there were a generic range operation, I would still favor the existing Len/Index methods for ranging arrays and slices and the Recv method for ranging a channel. |
|
I'm not particularly worried, especially about NaNs. It doesn't seem important enough to introduce yet more API here. |
|
This is a little sad. I was hoping there would be an efficient way to use reflect to range over a map. |
|
CL https://golang.org/cl/33572 mentions this issue. |
|
Another reason for this feature is that there's no way to iterate over a map while respecting deletions that occur during the iteration, as documented by the spec, making it impossible to implement a Go interpreter in Go using maps to represent maps. I've quickly sketched an implementation in https://go-review.googlesource.com/33572. |
|
There's something wrong with this issue: it's 1) open 2) assigned to a closed milestone (go1.6). I moved it to go1.9 and unlocked it. |
bradfitz
added
FeatureRequest
help wanted
NeedsFix
|
Would love to give this a go (found via https://dev.golang.org/imfeelinghelpful btw), any particular reason https://go-review.googlesource.com/33572 is marked as |
|
@kshvmdn, looks like the CL is marked for Go 1.10 and this issue are marked for Go 1.10. @alandonovan, what's the state of the CL? |
|
The CL works to the best of my knowledge but has not been reviewed by someone who knows the runtime. |
|
@bradfitz moved the CL to Go1.11 and so will I punt this issue to Go1.11 too, thanks for the CL @alandonovan and others for the discussions. |
ianlancetaylor
added
NeedsDecision
Example of use:
iter := reflect.ValueOf(m).MapRange()
for iter.Next() {
k := iter.Key()
v := iter.Value()
...
}
See issue #11104
Q. Are there any benchmarks that would exercise the new calls to
copyval in existing code?
Change-Id: Ic469fcab5f1d9d853e76225f89bde01ee1d36e7a
Reviewed-on: https://go-review.googlesource.com/33572
Reviewed-by: Keith Randall <khr@golang.org>
|
Fixed by ede5958. |
related issues: golang/go#23734, golang/go#11104 Update #3
The current reflect.Value interface for traversing maps requires allocating
all the keys at once (reflect.Value.MapKeys), which is not efficient for
huge maps.
Additionally, as floating point NaNs are never equal to each other, the
current interface makes it impossible to get the value for NaN keys.
We can introduce this
to solve the NaN problem, but I'm more interested in the first problem.
Actually, if we decide to introduce a range like operation on reflect.Value,
I think we should make it work for other range-able types (channels,
arrays, strings and slices) too.
The text was updated successfully, but these errors were encountered: