travisf
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?
Trending in Discussions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #ai
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #metaprogramming










Most Liked- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
stefanchrobot
I think that
ifworks great for boolean conditions and it’s often used in the Elixir’s codebase. I’d say thatcasewith justtrue/falsefeels weird.al2o3cr
optimize_booleanis a red herring here - it marks the enclosed AST so that a later pass can expand it:https://github.com/elixir-lang/elixir/blob/8d76faa3faf508b0f67835f9d1891aa484f9acda/lib/elixir/src/elixir_expand.erl#L688-L693
If the AST definitely has only true/false,
rewrite_case_clausesreplaces thewhen x in [false, nil]clause generated byifwith…case / endwith two branchesHowever, I don’t think it’s directly related to your situation since
returns_booleanhas a very specific list of things it’s looking for:https://github.com/elixir-lang/elixir/blob/8d76faa3faf508b0f67835f9d1891aa484f9acda/lib/elixir/src/elixir_utils.erl#L187-L225
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 :Sis helpful as ever, given this input:with_ifshows that thecasegenerated by the macro translates directly to aselectinstruction:with_sim_ifproduces exactly the same instructions (other than different labels for being in a different function):I’d expect that form to have exactly the same performance as
ifin your example.The code for the
casewith explicittrueandfalseis slightly different:This version has a third possible way to exit, if
argisn’ttrueorfalse.I suspect this may cause the performance difference - maybe an optimization in the JIT for simple branches?
There are some other interesting variations:
with_case_defaultuses_instead of true, so there’s no “third exit”. It produces very different instructions:I suspect this is competitively fast, if not faster than others.
with_if_eqshows theoptimize_booleanmachinery doing its thing - it optimizes to the same instructions aswith_case_default! Since the compiler knows==cannot returnnil, that part of the check has been removed:I’d expect this to perform identically to the
with_case_defaultform.with_case_whenandwith_if_whensupply the compiler with type information via anis_booleanguard, so they both produce identical instructions:eksperimental
I pretty much feel the same way you do.
I think
if/2is a good fit when you have:ifs under it,Other than that I prefer to use
caseandcond.condis particularly useful for replacing nestedifs orif/elseifs.Last Post!
BartOtten
If this is the case, a case could be made for if. Exception to the rule: when the else case raises. You have to try yourself.