What about defining a struct with default values, then using struct kernel function to map the values

@sigu
This case should not be the cause of using a struct. I mean the decision for a struct should be related to the problem and not to using some special syntax.
@PJUllrich
The idiomatic way for me is not to use pattern matching just for the case of extracting values from a map. The pattern matching in the parameters should have always a good reason.

For me foocould be written as:

def foo(data) do
  do_something(
    Map.get(data, "a"),
    Map.get(data, "b"),
    Map.get(data, "c"),
    Map.get(data, "d"),
    Map.get(data, "e", 10)
  )
end

or

def foo(data) do
  defaults = %{"e" => 10}
  %{"a" => a, "b" => b, "c" => c, "d" => d, "e" => e} = Map.merge(defaults, data)
  do_something(a, b, c, d, e)
end

@Marcus gives you a good way to go about it. I’ll offer one more:

defmodule Foobar do
  def foo(%{"a" => a, "b" => b, "c" => c, "d" => d, "e" => e}), do: do_something(a, b, c, d, e)
+  def foo(%{"a" => a, "b" => b, "c" => c, "d" => d}), do: do_something(Map.merge(params, %{"e" => 10}))
-  def foo(params), do: foo(Map.merge(params, %{"e" => 10}))

  def do_something(a, b, c, d, e), do: IO.inspect("#{a}-#{b}-#{c}-#{d}-#{e}")
end

I don’t think it’s bad to use Map.merge/2, but the way you use it as a fallback seems weird (and you wouldn’t have a base case if your map didn’t have an "a" key, for example).

Here’s how I would write your module:

defmodule Foobar do
  @default_params %{"e" => 10}
  def foo(params) do
    params = Map.merge(@default_params, params)
    do_something(params["a"], params["b"], params["c"], params["d"], params["e"])
  end

  def do_something(a, b, c, d, e) do
    IO.inspect("#{a}-#{b}-#{c}-#{d}-#{e}")
  end
end

But that may just be because of how I handle options to functions. I write a lot of single-public-function modules where I’m passing around the options to a lot of private functions and want the defaulting to happen in one place. They’ll look something like this:

defmodule My.Service do
  @default_opts %{charlie: true, delta: []}

  def call(alpha, bravo, opts \\ []) do
    opts = Enum.into(opts, @default_opts)

    with :ok <- validate_something(alpha, opts),
         {:ok, echo} <- do_something(alpha, bravo, opts) do
      {:ok, bravo + echo}
    end
  end

  ...
end

Sometimes only a single field is missing from the input map.

Is the missing field always the same, or does it vary? If the missing field is always the same then of course you’ll only need one default value .

I’m assuming the missing field can vary, in that case the way you wrote your code calls for a lot of pattern matching.

Not sure how you need to use your data in the end but assuming the map fields are known upfront I wrote it like this without the formatting.

defmodule Foobar do
  @fields ~w(a b c d e)

  def foo(map) when is_map(map) do
    Enum.reduce(@fields, [], &extract_values(&1, &2, map))
    |> Enum.reverse()
  end

  def extract_values(field, acc, map) do
    value = get_value(map[field], field)
    [value|acc]
  end

  def get_value(nil, field), do: default_value(field)
  def get_value(value, _field), do: value

  def default_value("a"), do: 1
  def default_value("b"), do: 2
  def default_value("c"), do: 3
  def default_value("d"), do: 4
  def default_value("e"), do: 10

end

Yes, the missing field is always the same.

Thanks a lot for your solution, however it feels a bit overkill
But it would be a good solution if any of the fields could be missing.

Hmm interesting! I like the second solution especially since it’s easily extendible if another field would be missing as well. Thanks!

I agree with @Marcus. I’d like to keep on using a map instead of having to define a struct for this function only. But if this case would be occurring in more than one function, the struct would actually be the way to go I think, so thanks