proposal: x/exp/maps: add Entries

[dsnet]

There are helper functions to extract the keys and the values, but not one to extract both together.

I propose adding:

type Entry[K comparable, V any] struct {
	K K
	V V
}

func Entries[M ~map[K]V, K comparable, V any](m M) []Entry[K, V] {
	r := make([]Entry[K, V], 0, len(m))
	for k, v := range m {
		r = append(r, Entry[K, V]{k, v})
	}
	return r
}

I often find myself sorting a map based on the value, but needing the key and value paired together.

This API would ease that pattern:

entries := maps.Entries(m)
slices.SortFunc(entries, func(x, y maps.Entry[K, V]) bool {
    return x.V < y.V
})

[rsc]

I'm skeptical about this. If we do this, maps.Entry[K, V] is going to end up all over everyone's code base as a generic pair type (in code that has nothing to do with maps).

[DeedleFake]

How about something that allows the user to use their own type via a function, such as

func EntriesFunc[K comparable, V any, M ~map[K]V, P any](m M, f func(K, V) P) (entries []P) {
  entries = make([]P, 0, len(m))
  for k, v := range m {
    entries = append(entries, f(k, v))
  }
  return entries
}

It seems a bit less useful to me, but it could still be useful in certain circumstances.

[ianlancetaylor]

@DeedleFake I feel like we're staying away from that kind of map/filter/reduce functions until we get a handle on iterators.

[DeedleFake]

If the goal is to collect it into a slice, the question of whether it'll need a predefined Entry or Pair type or not is still going to need answering.

[dsnet]

If we do this, maps.Entry[K, V] is going to end up all over everyone's code base as a generic pair type

That feels like unnecessary fear of what could happen. It would be more concerning if K was constrained to any rather than comparable. As it stand, it's not quite a fully generic pair type.

[rsc]

The comment says the API would ease this pattern:

entries := maps.Entries(m)
slices.SortFunc(entries, func(x, y maps.Entry[K, V]) bool {
    return x.V < y.V
})

but I don't see what happens next in this pattern. Is the code going to return a []maps.Entry? Why is that better than a more specific type? It's unclear why code would ever want to have a variable with type maps.Entry or []maps.Entry instead of something more specific.

[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

[ainar-g]

@rsc, the main use for this pattern in the code I work with is iteration of maps in a defined (here, sorted) order. So some kind of maps.Ordered(m, f(k K, v V) (cont bool)) API would probably cover a large part of the need for maps.Entries, at least in my experience.