Or even,

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

?

I like that even better :)

Although, you probably want to add Map in the name:

func (v Value) SetMapKey(it *MapIter)
func (v Value) SetMapValue(it *MapIter)

since the other map functionality have Map in the name: Value.MapIndex, Value.MapKeys, Value.MapRange, Value.SetMapIndex.

Or SetIterKey/SetIterValue.

I was looking at sources of allocations using reflect. Another that I found was something of the following pattern:

v.Set(m.MapIndex(k))

Ideally, we would be able to do this with an allocation-free API. Perhaps:

v.SetMapIndex(m, k)

Whatever names we chose here, I would hope that it doesn't steal a good name from this possible API.

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

The proposal seems to be to rename the functions so that

v.SetIterKey(it) is the same as (but more efficient than) v.Set(it.Key())
v.SetIterValue(it) is the same as (but more efficient than) v.Set(it.Value())

Is that right? Is there some kind of trick we can do in v.Set to enable these kinds of optimizations invisibly?

Is there some kind of trick we can do in v.Set to enable these kinds of optimizations invisibly?

That would be ideal. #48000 is the same class of problem with a similar proposed solution.

I'm not sure we can, as it.Key() and it.Value() are what are doing the allocations. Only when they are passed directly to Set() and nowhere else is the optimization possible.

I guess the compiler could have a special case for reflect.Set(it.Key()) (and perhaps other Set variants?) that calls into an unexported setIterKey in reflect. We haven't gone down the road of semantic-inlining the reflect package yet.

If the part of it.Key that allocates is inlinable, then maybe it's possible that calling v.Set(it.Key()) doesn't have to allocate on the heap because escape analysis can prove that the input to v.Set doesn't escape.

it.Key() needs to allocate on the heap regardless of escape analysis because the size it needs to allocate is not constant.

In order to avoid a copy, we need to know that no map write operation happens between it.Key() and the Set(). The only way I can see knowing that is to detect Set(it.Key()) in the compiler and rewrite that. Or make the user tell us using SetIterKey.

Thanks for the discussion about optimizations. It does seem like SetIterKey and SetIterValue are the way to go.

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

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

Change https://golang.org/cl/356049 mentions this issue: reflect: rename Mapiter.SetKey to Value.SetIterKey

Change https://golang.org/cl/356050 mentions this issue: doc: document new reflect.SetIter{Key,Value} functions