You mean you would expect it to do something like this?

Enum.map(keys, fn key ->
   case Map.fetch(map, key) do
     {:ok, value} -> {key, value}
     _ -> nil
   end
 end)

Perhaps, but I think that the name take is not obviously indicating one or the other case, so I personally don’t think it’s a bad name. Maybe it could have been called Map.pick, just to differentiate it from Enum.take which takes a number of elements, but renaming it now would have much bigger disadvantages than advantages in my opinion.

I expect it like this:

take = fn map, keys ->
  Enum.map keys, & Map.get(map, &1)
end

a = %{a: 1, b: 2, c: 3}
take.(a, [:b, :c])
> [2, 3]

Well, I don’t think it has to be renamed. Just want to know what other people think about it.

I find it quite understandable. I’ve always found slice hard to remember, even after many years of Ruby

My point is that you take values from map. I think, slice is not ideal either. But in my opinion, it is better that take.

You also take a subset. Language is tricky

The name take seems very natural to me. What you describe there could be done with %{a: 1, b: 2, c: 3} |> Map.take([:b, :c]) |> Map.values() (provided ordering is not important).

However, I have wanted a Map.values/2 that has an extra parameter to name which keys’ values you want.

Yes, I can, but I also can do it with several other ways. But oneliner is much prettier that 2 pipes.

That’s a very good idea!
Since Elixir already has Map.values/1 it could be a little effort to make that function.

You want a one-liner? You asked the right person

def values(%{} = map, keys) when is_list(keys), do: for {k, v} <- map, k in keys, do: v

Like a charm

FYI, I’m 90% sure that map |> Map.take(keys) |> Map.values is gonna win from a performance perspective because those are both BIFs.