Kword - A library of keyword-list handling functions to complement Keyword

I also read that post and liked it very much, however I think it missed one opportunity to make the code better with Keyword.validate!:

def update_user_details(opts \\ []) do
  opts = Keyword.validate!(opts, [:name, :email, role: :guest, gender: :unspecified]) |> Map.new()
  %{name: name, email: email} = opts
  # ...
end

By simply converting validated keyword list to a map you can use established Elixir idioms to check for required things, either by using opts.email notation, or by pattern matching. But maybe I’m missing something too

It highly depends on what kind of options you accept and how you treat them. The key concept when using keyword list vs map is that you can have duplicated keys in case of the list, then decide whether the new option overrides/appends to the old one.

“Considered Harmful” titles always make me think of “Considered Harmful” Essays Considered Harmful

I’m in favour of validating keyword args and do it myself (personally I use NimbleOptions) but that article hardcore handwaves through the entire premise of how they got there: how on earth did their tests not catch a mis-spelled option?? It sounds like they were passing the option but not actually asserting on its effects. Am I wrong or is there an obvious valid hiccup you can have here?

While it’s getting outside the realm of options, keywords also allow us to have order matter in the rarer situations where that’s useful:

from q in query,
  join: u in User,
  on: u.id == q.user_id,
  join: o in Org,
  on: o.id == u.org_id

Fair point, but with using Keyword.get or Keyword.pop you don’t really decide, just take the first value. Most of the usage of keyword lists outside of Ecto I see is a workaround for Elixir not having named arguments, so converting to map makes sense. However you’re right that to keep Keyword.gets behaviour in place you actually need Enum.reverse() |> Map.new().

Well, but we are in the realm of options.

I support everything that helps people make less mistakes and dynamic languages like Elixir don’t provide as much protection there.

So firstly, good job.

Secondly, the linked article does not sell the resulting library to me. Keyword.get and Map.get are something that many Elixir devs, myself included, consider an anti-pattern simply because they don’t discern between “I don’t have the key” and “I have the key but the value is nil” – in some situations this difference is meaningless but I’d bravely claim that in at least 80%, if not 90%, of the Elixir code I had to author or maintain that difference was in fact important but people ignored it and introduced bugs. So just by using functions like take and fetch you can replace most of the conveniences of this library – though granted, it would take more boilerplate so the library still looks compelling.

Thirdly, not comparing the new library with NimbleOptions is giving homework to the reader so I am going to skip it and just use the former instead.

The discussion is turning into a more general “why keyword lists over maps or bringing in keyword args,” so not quite, no.

Converting to Map was my first impulse, and I guess I should benchmark it but seems a bit heavyweight compared to constructing a list. Also there is the gotcha of Map.new taking the last one if a key occurs more than once.

I have seen NimbleOptions but bounced off when I saw how verbose it was, defining a schema with types. Looking closer now I do think there would be times I’d want exactly that.

The aim of Kword is to provide a few relatively fast functions that I found myself wishing were in the Keyword module.

Oh ya, I got that! I wasn’t speaking against the utility of your library, just criticizing the article you linked.