Let's talk about Guards

My rule of thumb is to use them when I need them. Or what do you mean?

And what do you mean by “errors from guards”? If something raises in a guard, it is considered as if the whole guard is false.

My rule of thumb is to use them when I need them. Or what do you mean?

I like guards, because they constrain the types of arguments, and force me to think about cases when they are not.

Somehow, it seems that using them for every function might be overkill.

On the flip side, the more you use them the more helpful Dialyzer checks will be, due to the constraints guards put on your functions…

Plus documentation - as opposed to type specs, if they go out of sync with your code, you will be forced to update them to keep things working…

I.e. perhaps there is no such thing as overkill when using guards…

To flip the question around: when do you need them?

And what do you mean by “errors from guards”?

For example, if I have something like,

def id(s) when is_binary(s), do: s
def id(s), do: nil

would you rather return nil or :error or {:error, "Argument is not a String"}.

I suppose it depends on the specific function, eh? Doubt there’s an idiomatic guard / type error?

Well, Guards are so much more than only checking for the type of an argument. I do usually only check for the type in public functions and in my private functions I do simply assume “everything is correct”.

It depends. But usually I do use an error-tuple or I crash. Also the case you drafted is not an error from a guard, its simply an unmatched function head. An error in a guard is the following:

def foo(a) when is_binary(a) && a + 1 <= 0, do: :unreachable

As this will raise. But that is “gulped” by the runtime and the whole guard is considered “unmatched” and the next function head is tested.

I do usually only check for the type in public functions and in my private functions I do simply assume “everything is correct”

Aha, OK, so you have a public / private rule of thumb

I never thought about it that way before, that perhaps is a good way to go about ‘guarding’ functions

Well, for those typeguards, yes. But as I said, there is so much more in guards than only checking for types.

when you have a chance, pls elaborate

I use guards in two cases:

1. To help with pattern-matching when I have multiple functions. Usually these functions are then ‘complete’ (as opposed to ‘partial’ functions).
2. To constrain the input types of the functions, especially when they are part of the public API of whatever it is I am writing.

Ahh… So you also have the public / private split. V good.

You can use guards to check if arbitrary conditions hold (well, nearly arbitrary)

def wordy_age(age) when age in 0..2, do: :baby
def wordy_age(age) when age in 3..6, do: :preschooler
...
def wordy_age(age) when age > 100, do: :methusalem

You can use them as a complement to a patternmatch (edit: qqwy already named that, example:)

  defp get_task(%{:type => a} = element, socket) when a in ["exclusiveGateway","parallelGateway"],
    do:  get_tasks_after_element(element.id, socket)