Still, the structure preserving Enum.map would be not possible in case like:

map = %{2 => 1, 3 => 7}

Enum.map(map, fn {a, b} -> a + b end)

As mentioned before, Enum.map on a map returns a list because this would fit better to pipes without the need to convert to a list and back behind the scenes in every step.

There used to be the Map.map/2 function in Elixir, which is now deprecated. But you get the same result with Map.new/2.

iex(1)> map = %{a: 1, b: 2, c: 3}
%{c: 3, a: 1, b: 2}
iex(2)> Map.map(map, fn {key, value} -> {key, value * value} end)
warning: Map.map/2 is deprecated. Use Map.new/2 instead (invoke Map.from_struct/1 before if you have a struct)
└─ iex:2

%{c: {:c, 9}, a: {:a, 1}, b: {:b, 4}}
iex(3)> Map.new(map, fn {key, value} -> {key, value * value} end)
%{c: 9, a: 1, b: 4}

One thing is that the result of your map operation is in a predictable order. I don’t have a real world example of where this would particularly useful, but in a pipeline it could be. Having each result getting converted back to a map would be pretty chaotic.

Yep, I also checked the Elixir source a while ago. IMO doing Map.new only once is more performant than doing N times Map.put so I am always doing that.

I’m not sure how to respond to that. Fwiw this quote from docs might be helpful:

https://hexdocs.pm/elixir/1.16.2/Collectable.html#module-why-collectable

The Enumerable protocol is useful to take values out of a collection. In order to support a wide range of values, the functions provided by the Enumerable protocol do not keep shape. For example, passing a map to Enum.map/2 always returns a list.

This design is intentional. Enumerable was designed to support infinite collections, resources and other structures with fixed shape. For example, it doesn’t make sense to insert values into a Range, as it has a fixed shape where only the range limits and step are stored.

The Collectable module was designed to fill the gap left by the Enumerable protocol.