proposal: spec: keys/vals function for map types

[eaigner]

It's quite a common case to use maps to ensure values are unique.

I wondered if the hashmap implementation could expose it's keys and values directly via
a `keys` and `vals` builtin, instead of creating a slices, iterating over the map and
filling the slice. It would also help to avoid creating unnecessary gargabe when only a
reference is obtained.

[cznic]

Comment 1:

Not sure what's this about. Please elaborate on the specification of "expose it's keys
and values directly via a `keys` and `vals` builtin". Also an usage example would be
great to illustrate how a specific problem is solved by the proposal.

[ianlancetaylor]

Comment 2:

There is no way to avoid allocation if you want to convert a map's keys to a slice of
keys, since the map does not store its keys in a slice.
You could write a version of these functions today using the reflect package.
Other than that I don't think this is a likely extension, but it is a possible one so
I'll leave it open for now.

Labels changed: added release-none, repo-main, languagechange.

[eaigner]

Comment 3:

#1 What I meant is the following:
  var m map[string]int = ...
  keys := make([]string, 0, len(m))
  values := make([]int, 0, len(m))
  for k, v := range m {
    keys = append(keys, k)
    values = append(values, v)
  }
Instead one would write
  keys := keys(m)
  values := vals(m)

[randall77]

Comment 4:

I think what Ian is saying is that your keys() and vals() operations necessarily need to
make a copy, as the underlying data isn't laid out as a slice.  So while such ops would
make your job syntactically simpler, the underlying implementation wouldn't be any
simpler (it would create the same garbage either way).
There might be less garbage if the keys were large and keys(m) returned a slice of
pointers to keys.

[extemporalgenome]

Comment 5:

If keys and vals builtins were implemented as described, then there'd be no reason why
([]interface{})([]T) wouldn't also be justifiable.

[nathany]

This is similar to other requests for builtin generic functionality, such as map/reduce #14173. Otherwise keys/values could be implemented or generated for each map type desired.