beno
I will often find my self writing things similar to:
case some_value do
nil -> something()
"" -> something()
_ -> something_else()
end
So in other words I have multiple match clauses that resolve to the same outcome. I makes me want to write something like:
case some_value do
nil | "" -> something()
_ -> something_else()
end
Of course in this case you’d probably turn the clauses around, but that is usually not desirable or in sync with my thinking about the problem. I can think of other solutions as well, but what is the most Elixiry way of tackling this?
Trending in Questions
Hey guys,
I’ve got a huge CSV ( around 10 GB ) that needs to be processed hourly
Do you guys have any suggestions what is the best prac...
New
Hello!
Could someone please give me a help/sample code, how to delete a file from s3 using waffle/waffle_ecto from Phoenix app.
I creat...
New
I have what I’ve heard referred to as a “lookup table” in my database. This is a way of assigning codes to common values. One common lo...
New
What approach to take when sending live updates to “random” users Hi! I have a question, I have a little chat app, and when I create a DM...
New
I’m seeing that a list inside a Kino.DataTable will be interpreted as a charlist, even if the Kino.configure() is set to charlists: :as_l...
New
Anyone here using Honeybadger?
My Honeybadger account is being overwhelmed with noise from some bots. Seeing a lot of
Bandit.HTTPError...
New
Hi, I’ve just set up an application with ash_authentication. There is only magic link strategy for now, so there is no confirmation add o...
New
Other Trending Topics
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Hobbes is a low-level distributed database for the Elixir programming language.
Hobbes provides a simple, safe, and scalable storage lay...
New
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve.
They are GUI (Emerge) and State management (S...
New
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
There are three potential reasons for members of this forum to have a look at https://vutuv.de
You are tired or annoyed of LinkedIn.
Yo...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixir-ls
- #elixirconf-us
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
net
beno
Thank you very much. I will be using this from now on.
NobbZ
This only works kind of.
1 in [1.0]is true when I’m remembering correctly. Also sometimes you want to bind parts of the different matches. That won’t work with your guard as well. Last but not least guards can’t get compiled into a trie and therefore slow down the overall match.benwilson512
I think your overall point is good but this is in fact false, both in matches and in the general case:
NobbZ
Ok, then I mid remembered the semantics of
in. The issue of bindings still applies and the fact that guards do affect the performance as well. So 2 of 3 issues remaining.OvermindDL1
To be specific, the right argument of the
in/not inoperator must be statically known at compile-time when used in guard position, so you cannot do something like:This is because in guard position the
inoperator works differently than in non-guard position (I really dislike inconsistencies like this), specifically it gets expanded, so the above example when written like:Actually gets compiled to (you can check with a core erlang dump):
EDIT: It also works with ranges:
Gets turned into: