Today's Advent of Code puzzle inspired me to create this TIL. It may sound trivial, but in fact, it's tricky if you are unfamiliar with the nuances of guards' functioning.

Table of contents

    Usually, you would write Map.has_key?(map, key) , but it's forbidden in guards since, in them, you can only use expressions from a strictly limited list.

    ** (CompileError) iex:11: cannot invoke remote function Map.has_key?/2 inside guards
        (elixir 1.13.1) src/elixir_fn.erl:17: anonymous fn/4 in :elixir_fn.expand/4
        (stdlib 3.17) lists.erl:1358: :lists.mapfoldl/3
        (elixir 1.13.1) expanding macro: Kernel.|>/2

    What about in?

    Unfortunately, unlike in languages like Python or Javascript, Elixir's inmacro doesn't check for key inclusion in a given map.

    is_map_key/2 for the help

    Elixir 1.10.0 introduced a new function allowed in guard tests - is_map_key/2 .

    Let's see an example:

    iex(1)> variables = %{"a" => 5}
    ...(1)> translated = Enum.map(["a", "b"], fn
    ...(1)>   name when is_map_key(variables, name) -> variables[name]
    ...(1)>   name -> name
    ...(1)> end)
    [5, "b"]

    This code replaces all occurrences of known variable names in a given list with their values.

    You probably don't need an is_map_key/2

    Constructions like the above are rather rare. In most cases, you can get the job done using good old pattern matching.

    If you already know which key you are looking for, a much better option is to create multiple function clauses:

    def has_user?(%{user: _}), do: true
    def has_user?(_), do: false
    Artur Ziętkiewicz
    Artur Ziętkiewicz Elixir & React Developer

    Read more
    on #curiosum blog

    Debugging Elixir Code: The Definitive Guide

    Debugging Elixir Code: The Definitive Guide

    Every application contains bugs, and even if it doesn't, it will. And even if you're not a notorious bug producer and your code quality is generally good, the conditions programmers work in are often suboptimal - you will often find yourself pulling your hair out over code written years ago by someone no longer involved in your project.