Please explain inconsistency with :erlang.map_get(key, map) in guards


If in a guard I use :erlang.map_get/2 on a map that does not have the key, and use a or to put another guard condition in second position, the second condition will not be evaluated.

defmodule T do
  def check_nil_1(map, key) when :erlang.map_get(key, map) == nil or not is_map_key(map, key),
    do: true

  def check_nil_1(_, _),
    do: false

  def check_nil_2(map, key) when not is_map_key(map, key) or :erlang.map_get(key, map) == nil,
    do: true

  def check_nil_2(_, _),
    do: false

map = %{a: 1}
key = :b

T.check_nil_1(map, key)
|> IO.inspect(label: "check 1")

T.check_nil_2(map, key)
|> IO.inspect(label: "check 2")

# Output:
# check 1: false
# check 2: true

I expected both checks to be true. The only difference is the order of the conditions in the guards. The documentation says:

The call fails with a {badmap,Map} exception if Map is not a map, or with a {badkey,Key} exception if no value is associated with Key. […] Allowed in guard tests.

Obviously as it is in a guard it does not fails with an error, but the docs do not tell that it also skips further evaluation of the guard conditions.

So, are there any more docs on that subject ? And any other special cases in guards that would be good to know ?

Thank you

(edit: if the key exists in the map with a nil value, both checks return true as expected.)

map_get raises if the key does not exist on the map and or only executes the right-side if the left-side is false. Therefore, in the first case, when you do the map_get for a key that does not exist on the map, it will fail and never execute the right-hand side of or.


As an alternative if you want a particular function clause to be called even if an earlier guard of this clause raises, you might use multiple guards in the same clause.


Ah thanks, I saw such a construct on a post from rvirding but immediately lost the browser tab so I could not verify and could not find the exact syntax again. I have been thinking since that is was an hypothetical thing ^^

Oh and the docs you linked actually tell about the guard failure:

However, recall that if any function call in a guard raises an exception, the entire guard fails.