Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: spec: keys/vals function for map types #7057

Closed
eaigner opened this issue Jan 3, 2014 · 7 comments
Closed

proposal: spec: keys/vals function for map types #7057

eaigner opened this issue Jan 3, 2014 · 7 comments
Labels
FrozenDueToAge LanguageChange v2 A language change or incompatible library change
Milestone

Comments

@eaigner
Copy link
Contributor

eaigner commented Jan 3, 2014

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
Copy link
Contributor

cznic commented Jan 3, 2014

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
Copy link
Contributor

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
Copy link
Contributor Author

eaigner commented Jan 3, 2014

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
Copy link
Contributor

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
Copy link
Contributor

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.

@bradfitz bradfitz removed the new label Dec 18, 2014
@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@nathany
Copy link
Contributor

nathany commented Mar 16, 2016

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.

@rsc rsc changed the title builtin: keys/vals function for map types proposal: spec: keys/vals function for map types Jun 20, 2017
@rsc rsc added the v2 A language change or incompatible library change label Jun 20, 2017
@ianlancetaylor
Copy link
Contributor

Any implementation of these functions has to make a copy, so there is no way to generate less garbage than the hand written implementation. We aren't going to do this special case. Closing.

@golang golang locked and limited conversation to collaborators Dec 13, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge LanguageChange v2 A language change or incompatible library change
Projects
None yet
Development

No branches or pull requests

9 participants