I’m curious what the consensus (if there is one) on case vs if statements for conditionals is. Specifically, in cases where you are only dealing with boolean options for example not is_nil(value).
Personally, when I write Elixir I find that I reach for case way, way more than if even when if would work fine. I think I do it because I don’t always know all the potential conditionals when I start writing the function, I like the sort of open ended nature of case as one can add other cases over time. I also just find something visually unappealing about if statements compared to case when I read Elixir code.
I’m not totally against if I use it from time to time when I know that there will only ever be two conditions or when I can do a single line: if foo, do: func(foo), else: func(bar).
Is this an anti-pattern is there a good reason why I should start using if more regularly?
I was doing LeetCode and was solving a problem by reducing an enumerable, where the reducer does different things to the accumulator based on whether a condition is true or false.
I didn’t think much about the difference between if-else and case. So I did this:
case MapSet.member?(acc, item) do
true -> {:halt, true}
false -> {:cont, MapSet.put(acc, item)}
end
And the runtime was 655 ms, better than 25% solutions.
I tried using if instead, the runtime was 525 ms, that is 100 ms shorter and better than 100% solutions.
In conclusion, if you are only dealing with true or false, if-else is definitely faster.
Yeah absolutely doesn’t make any sense. case is an erlang construct that is considered a core operation, while if is a syntactic sugar (AKA macro) that uses case under the hood, you can inspect the source code yourself.
optimize_boolean is a red herring here - it marks the enclosed AST so that a later pass can expand it:
If the AST definitely has only true/false, rewrite_case_clauses replaces the when x in [false, nil] clause generated by if with… case / end with two branches
However, I don’t think it’s directly related to your situation since returns_boolean has a very specific list of things it’s looking for:
and MapSet.member? isn’t on that.
A more interesting (IMO) thing to look at around performance is the shape of the BEAM code produced by the compiler. @compile :S is helpful as ever, given this input:
defmodule Foo2 do
@compile :S
def with_if(arg) do
if arg do
:ok
else
:nope
end
end
def with_sim_if(arg) do
case arg do
false -> :nope
nil -> :nope
_ -> :ok
end
end
def with_case(arg) do
case arg do
true -> :ok
false -> :nope
end
end
def with_case_default(arg) do
case arg do
false -> :nope
_ -> :ok
end
end
def with_if_eq(arg) do
if arg == false do
:nope
else
:ok
end
end
def with_if_when(arg) when is_boolean(arg) do
if arg do
:ok
else
:nope
end
end
def with_case_when(arg) when is_boolean(arg) do
case arg do
true -> :ok
false -> :nope
end
end
end
with_if shows that the case generated by the macro translates directly to a select instruction:
I suspect this is competitively fast, if not faster than others.
with_if_eq shows the optimize_boolean machinery doing its thing - it optimizes to the same instructions as with_case_default! Since the compiler knows == cannot return nil, that part of the check has been removed:
My guess (not gonna bother checking the bytecode unless people REALLY want) is that optimize_boolean ALSO has a list of “known functions with strictly boolean output” for example, and, or (vs &&, ||) and is able to eliminate the nil check from the if statement.
Well if it doesn’t do that, it probably should. It could probably also optimze some known stdlib functions, like Map.has_key?, etc.
Worth pointing out MapSet.member?(map_set, element) does not strictly return a boolean—it also raises if map_set is not a %MapSet{}. This is probably part of the reason why it’s not on the list. (The same holds true with Map.has_key?/2).
I rarely use if, if you have multi return values from one pattern(for example case x do 1->... 2->...) then go with case do, but if you’re dealing with many patterns that are almost booleans (for example if x==1....if y ! =2 then cond do will be perfect
