reflect: add MapIter.SetKey, SetValue, and friends

[rsc]

Over at #32424 (comment), @randall77 suggests that a performance problem with map iteration can be fixed by adding MapIter.SetKey and MapIter.SetValue methods.

It's possible others should be changed but this is the most significant from a performance standpoint.

[rsc]

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

[gopherbot]

Change https://golang.org/cl/320929 mentions this issue: reflect: add MapIter.SetKey and MapIter.SetValue

[rsc]

/cc @randall77; any reason not to do this?

[randall77]

No, sounds fine to me.

[rsc]

Does anyone object to adding these?

[rsc]

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

[rsc]

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

[dsnet]

Minor bikeshed, I was a little confused by the direction of setting. In reflect, we have:

func (v Value) Set(x Value)
func (v Value) SetBool(x bool)
func (v Value) SetBytes(x []byte)
func (v Value) SetCap(n int)
func (v Value) SetComplex(x complex128)
func (v Value) SetFloat(x float64)
func (v Value) SetInt(x int64)
func (v Value) SetLen(n int)
func (v Value) SetMapIndex(key, elem Value)
func (v Value) SetPointer(x unsafe.Pointer)
func (v Value) SetString(x string)
func (v Value) SetUint(x uint64)

All of theses take the input argument and store it into the receiver, v.

Now we added:

func (it *MapIter) SetKey(dst Value)
func (it *MapIter) SetValue(dst Value)

However, contrary to reflect.Value.SetXXX, it is state in the receiver that it being store into the input argument. It is the opposite direction.

Perhaps we should rename it as SetKeyInto and SetValueInto?

[josharian]

Perhaps we should rename it as SetKeyInto and SetValueInto?

Or StoreKey and StoreValue?