Why do we need to use Enum.into(%{})?

You don’t have to. You can call reduce over new map like this:

iex> Enum.reduce(%{a: 1, b: 2, c: 3}, %{}, fn {key, value}, acc ->
  Map.put(acc, key, value * 2)
end)
%{a: 2, b: 4, c: 6}

Note: The order of map elements is not guaranteed to be sorted.

But, I don’t know, seems like extra work. I’m so used to it that it doesn’t bother me that much, I just thought that it was an odd implementation detail.

Maybe we need an Enum.fmap/2 like Haskell?

Using Enum.map or Enum.reduce and working with two-tuples and then just doing Map.new does not justify the need for a function that does the same IMO. Just do your stuff and slap a Map.new at the end.

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.

Oh, right I forgot about it. Unfortunately we do not have a way to map the Map without converting it first to a list, see:

https://github.com/elixir-lang/elixir/blob/349321117ebb598cd10a4f22e8ea8e1c4b13b6c8/lib/elixir/lib/enum.ex#L4879-L4881

https://github.com/elixir-lang/elixir/blob/41f6ee3f2e605f7066b23d96362e3b0c620c565b/lib/elixir/lib/map.ex#L248-L264

So at the very end we do exactly the same.

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.

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}

Except when the input is a map, there is no guarantee about order in the first place. So this argument doesn’t seem to hold.

For the argument that conversion would take place between steps in a pipe; why would it? Elixir can detect it is in a pipeline and not convert in between as an optimization.

Once you know the ‘conversion’ it does not matter that much anymore. But I see how returning the same type as the input makes sense from a developer experience.

The output type of Enum.map (and most Enum functions) cannot be the same as the input type because Enum works on a variety of data types through the Enumerable protocol. A simple example is:

iex> Enum.map(1..3, & &1 ** 2)
[1, 4, 9]

We couldn’t possibly keep the shape of the input, %Range{}, because the end result would be nonsensical. Some other things that implement Enumerable protocol are file streams and even infinite streams.

As was mentioned before there used to be a Map.map/2 but it got deprecated because a similar function existed all along, Map.new/2:

iex> Map.new(1..3, fn i -> {i, i ** 2} end)
%{1 => 1, 2 => 4, 3 => 9}

so yeah, long story short, in your particular case instead of Enum.map/2 use Map.new/2.

Seems an implementation detail in the case of Range. From an outside perspective the range simply expands to a list so a list in return makes sense. As far as I can see the sole reason for having a ‘Range’ struct during processing is optimization, and explicit use of the struct is deprecated.

—-snip this part: Too early in the morning—-
—- and the start was incorrect too, see below —-