Decisions: case, cond and guards

case: one path per shape

A case compares a value against patterns, top to bottom, and the first pattern that fits wins. Because the patterns are matches, they also name the parts you need: {:ok, temp} hands the branch a temp to work with. The patterns are tried in the order written, so a specific pattern belongs above a general one that would also fit.

Each branch is a pattern, an arrow, and the answer for that case. The branch you land in decides the value of the whole case, so you can hand a case straight to a function or print it. There is no fall-through and no break — one pattern, one path. The value the case answers is the value of the branch that ran, so it can sit inside a string interpolation or be handed to a function without a temporary name.

Guards: when the shape is not enough

Sometimes a pattern fits but you want more: a temperature above 25, a number that is really a number. A guard does that with when after the pattern, as in {:ok, temp} when temp > 10 ->. If the guard fails, the case moves on to the next clause as though the pattern had not fitted at all. That is the important difference from an if inside the body: a failed guard moves to the next clause, so guards are how a case chooses between several versions of the same shape.

Guards also sit on function heads, which is how a module can offer one function name that behaves differently for different inputs. Only a small, safe set of checks is allowed inside a guard — comparisons, arithmetic, and the is_ checks such as is_integer and is_atom. The restriction is deliberate: a guard can never run your code, so it can never fail in a surprising way. The compiler enforces the list, so a call to String.length in a guard is rejected before the program runs.

cond, if, and what counts as true

A cond is a ladder of conditions rather than a match on a shape. Each line is a condition and an answer, and the first condition that is true wins. The last rung is usually just true, which catches everything the earlier rungs missed. Use cond when several different questions have to be asked in order, and case when one value has several possible shapes. A cond can ask about different values on each rung, which is exactly what a case cannot do: a case has one subject and matches every clause against it.

For a single yes-or-no question there is if, and its mirror unless. In Elixir only false and nil count as false — every other value is true, including 0 and the empty string. That is a smaller rule than most languages have, and it means a test that looks for emptiness has to say what it means.

A guard, a case, and a cond

defmodule Grade do
  def label(score) when score >= 90, do: :great
  def label(_score), do: :keep_going
end

IO.inspect(Grade.label(95))
IO.inspect(Grade.label(70))

reading = {:ok, 12}

case reading do
  {:ok, temp} when temp > 10 -> IO.puts("warm: #{temp}")
  {:ok, temp} -> IO.puts("cold: #{temp}")
  {:error, reason} -> IO.puts("failed: #{reason}")
end

band = fn n ->
  cond do
    n > 100 -> :big
    n > 10 -> :medium
    true -> :small
  end
end

IO.inspect(band.(500))
IO.inspect(band.(50))

What a guard may do

A guard is deliberately poorer than a function body. It may compare, do arithmetic, and call a small set of is_ checks, but it may not call your code or a function such as String.length. The restriction is what makes a guard safe: the runtime can evaluate it without side effects and without the possibility of raising, so a failing guard simply moves on to the next clause.

cond asks its questions in order and stops at the first true one. If none is true it raises, which is why the last rung is usually the literal true. case is different: it matches shapes, and a guard can narrow a shape but cannot replace it.

Try these next

• Write a case for {:ok, n} and {:error, reason} that prints a different sentence for each.
• Add a guard to a function head so it accepts only positive integers.
• Rewrite a two-branch if as a cond with a final true rung.