Just that would not guarantee that the order of the values is the same as keys.
lucaong
LukeWood
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
Good point! I’m actually not sure what the expectation of a Map.values/2 would be now that you mention it. Map.values/1 makes no particular guarantee about value order. I suppose Map.values/2 is a lot more useful though if it does do things in the order of the supplied keys.
3
air
OK, guys. As far as I understand everyone is satisfied with name take. What about values/2? Do I get it right that there will be a proposal to include that function?
0
ityonemo
I’m pretty happy with Map.take (and I use it all over the place). At least it’s consistent with Keyword.take.
My only tangentially-related wish is that Map.merge/2 let you use a keyword-list.
1
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
You can use Enum.into for this:
iex(1)> [a: 1, b: 2] |> Enum.into(%{c: 3})
%{a: 1, b: 2, c: 3}
I like values/2. There will only be a proposal if someone makes one though. The official place to make proposals like this is the elixir-lang-core mailing list here Redirecting to Google Groups
You’ll want to reference this thread as a place where the initial conversation took place and some support for the idea found.
0
ityonemo
bjunc
I think a lot of what will influence whether someone finds the vocabulary intuitive will be based on experience in other languages. For instance, slice wouldn’t likely make sense to someone coming from JS, as that returns a list using index and length as arguments (same as Enum.slice/2).
In other languages, I have seen take() used exclusively in the context of lists; with a different method used for collections (eg. pick or pluck). Essentially, the deciding factor of take vs pick is whether the response includes keys.
In Elixir, take seems to be used for consistency, with the response being contextual (but matching the original type). For instance:
Enum.takereturns a list with no keysKeyword.takereturns a keyword (list with keys)Map.takereturns a map
If Elixir were to apply the “take for no keys, and pick for keys” convention, then it might look like this:
Enum.take/2 returns a list with no keys
Enum.take(["foo", "bar", "baz"], 0)
# ["foo"]
Keyword.take/2 returns a list with no keys
Keyword.take([foo: "bar"], [:foo])
# ["bar"]
Keyword.pick/2 returns a keyword list with keys
Keyword.take([foo: "bar", baz: "qux"], [:foo])
# [foo: "bar"]
Map.take/2 returns a list without keys
Map.take(%{foo: "bar", baz: "qux"}, [:foo])
# ["bar"]
Map.pick returns a map with keys
Map.pick(%{foo: "bar", baz: "qux"}, [:foo])
# %{foo: "bar"}
I think I could get behind that, but it can also be a little tricky since you’re not always getting back the same type that you started with (losing the consistency that the current implementation provides). 
Remember, the hardest part of writing code is knowing what to name things!
1
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
One thing I’m realizing is underspecified about values/2: What should it do if you pass it a key that isn’t in the map? Raise? Return nil? Ignore it?
1
lucaong
Yep, that’s why in my first reply I was returning entries as {key, value} tuples, or nil if missing. But then of course Map.values/2 is the wrong name. Maybe Map.entries/2?
In the end, I feel this is something that one can build on top of the provided core functions and adapt it to the specific need. Not a good candidate for a new core function in my opinion.
1