My usual way is to convert Keywordlists to Maps, then use the map:

def my_fun(options, sup_opts) when is_list(options), do: options |> Enum.into(%{}) |> my_fun(sup_opts)
def my_fun(opts = %{a: false, b: _}, sup_opts), do: # this is case 3
def my_fun(opts = %{a: false}, sup_opts), do: # this is case 1
def my_fun(opts = %{a: a, b: b}, sup_opts), do: # this is case 2
def my_fun(opts = %{a: _}, sup_opts), do: # this is case 4
def my_fun(opts = %{b: _}, sup_opts), do: # this is case 5
def my_fun(opts = %{}, sup_opts), do: # this is case 6

beware of the fact, that I had to reorder your requirements in a way that previous patterns do some filtering. Here case 1 will match on :a beeing false, but it will never see a Map containing a :b as key, since those match on the previous clause for case 3, but if you swap them you will never reach case 3, because case 1 would always match.

@NobbZ’s approach is superior if you are going convert the keyword list to a Map anyway (for later convenience). But I don’t see anything wrong with the “low-tech” approach if you are trying to stick with the keyword list:

defmodule Demo do

  defp my_fun_do_it(_options, _sup_opts),
    do: IO.puts "Do it!"

  def my_fun(options, sup_opts) do
    case {Keyword.fetch(options, :a), Keyword.fetch(options, :b)} do
      {{:ok, false}, {:ok, _b}} -> IO.puts "Error case 3"
      {{:ok, false}, _}         -> my_fun_do_it(options, sup_opts)
      {{:ok, _a},    {:ok, _b}} -> my_fun_do_it(options, sup_opts)
      {{:ok, _a},    _}         -> IO.puts "Error case 4"
      {:error,       {:ok, _b}} -> IO.puts "Error case 5"
      _                         -> IO.puts "Error case 6"
    end
  end
end

(Demo.my_fun [a: false], [])
(Demo.my_fun [a: nil, b: nil], [])
(Demo.my_fun [a: false, b: nil], [])
(Demo.my_fun [a: nil], [])
(Demo.my_fun [b: nil], [])
(Demo.my_fun [], [])

$ elixir demo.exs
Do it!
Do it!
Error case 3
Error case 4
Error case 5
Error case 6

Note however that there is a subtle difference in the “fetch” and “convert to Map” approach. Given that keyword lists can have multiple occurrences of the same key “fetch” will simply grab the first occurrence while the “conversion to Map” will only contain the last occurrence.

iex(1)> Keyword.fetch([a: false, a: 0],:a)
{:ok, false}
iex(2)> Keyword.fetch([a: 0, a: false],:a)
{:ok, 0}
iex(3)> [a: false, a: 0] |> Enum.into(%{}) 
%{a: 0}

Whether or not that makes a difference depends entirely on the circumstances.

Which can be easily worked around:

iex(1)> [a: false, a: 0] |> Enum.reverse |> Enum.into(%{})
%{a: false}

The fact I was nudging towards was that a keyword list can have multiple values for a single key.

However in 99.9% of the cases there is no intent to support multiple values per key - and nothing in the original post suggested that there was any intent to support multiple :a or :b values.

I suspect keyword lists being the default mechanism for passing options to Elixir functions motivated the choice here - not the fact that a keyword list can have multiple values for the same key.

At the same time I’m not aware of a convention that suggests which value should be given preference when an option appears multiple times in an option list - the one closest to the beginning of the list or the one closest to the end?(‡)

My choice would be to pass options in a Map to begin with but I suspect that the “option keyword list mechanism” was devised during a time where there were no Maps but only HashDicts (Edit: The reasons are actually quite different).

Again - in 99.9% of the cases the possibility of multiple values per key is a non-issue but it probably doesn’t hurt to keep this potential “gotcha” in mind.

‡ Based on José’s comment:

so

> Enum.into([a: 2, a: 3], %{a: 1})
%{a: 3}

the last value should likely be the “honoured” value (which interestingly could be the “first” value added to the list when it was created by cons-ing) if only one value is desired. However since something like for cmd_opts reverses the order of the options during validation, I guess, no definitive call can be made.

I’m thinking idiomatic “Keywords -> Map” conversion shouldn’t be:

iex(1)> [a: 1, b: 2, a: 3] |> Enum.into(%{})
%{a: 3, b: 2}

but

iex(2)> [a: 1, b: 2, a: 3] |> Enum.reverse() |> Enum.reduce(%{}, fn({k,v}, acc) -> (Map.update acc, k, [v], &([v|&1])) end)
%{a: [1, 3], b: [2]}