I have trouble imagining a scenario in my own code when I wouldn’t use a case for something that has more than one valid return value.
Tyson
1
Tyson
Also think it’s rare for me to write a function that has multiple return types (as distinct from multiple return patterns).
1
DidactMacros
{:ok, x} when match?(is_integer x, my_function())
The problem is this is a macro so these functions won’t be evaluated, but you can override the Kernel.match? With your own and using bindings you could have these parameters evaluated prior to being passed to the macro.
Inside your custom macro you would then use the Kernal.match? this will let you know whether the first arg value is of a matching pattern to the second.
Actually,
fun = fn 5 -> [ok: 5] end
match? [ok: 5], fun(5)
true
works from Kernel, but match? is considered a “case” orderflow, so it won’t work with guards. I don’t know if a custom version will have the same outcome.
1
derek-zhou
I’d rather write:
defp unwrap_integer!({:ok, x}) when is_integer(x), do: x
x = my_function() |> unwrap_integer!()
Instead of asking “why not”, I’d rather ask “how do I write what I want using what is available to me”
3
giddie
Unless I’ve lost track of your train of thought, are you saying that a success case must always have more than one valid return value? I’m on board with the top quote, for sure: I like to define the success case, and for me that means sometimes I just want to specify that the data should be an integer when I extract it from a map, for instance:
%{"my_key" => value} when is_integer(value) = my_map
I could use a case, for sure. But it would use two additional lines and add unnecessary noise. And I’m just wondering why this more concise syntax is not available.
Note that adding additional branches to a case here to handle an other case would be needlessly defensive - I don’t need to pattern-match an unexpected error case when I could just let it crash out.
1
giddie
OK, so that covers the integer case. Now you need to write the same function again for every possible combination 
Imagine I’m extracting an integer from a struct field, for instance?
This does sound sensible, but actually I question the wisdom. Naturally, we can only use what we have available to use. That is a truism. But questioning why things are the way they are can lead us to improve the whole shebang for everyone.
0
derek-zhou
I thought I helped?
You have your pet peeve and I have mine. This is free software so let the do’er decide.
0
Tyson
Definitely not!
I’m trying to imagine circumstances where return value x could have multiple possible types but you wouldn’t want to branch on them with case.
3
dimitarvp
I don’t understand the criticism towards OP here, especially by @sodapopcan and @D4no0.
Guards “should not” be used for type checking? Why not? How does it make the code bad or unreadable or untenable? Nobody is saying “do it on every assignment”. Do it at the function edges as @zachallaun alluded to.
Not sure I am not splitting hairs here because I might be taking your comment too verbatim – let me know (you might also include pattern-matching in function heads but I assumed you didn’t).
Still, picture my case, when a very old API returns prices in three different types because the old code had subtle bugs that nobody wants to fix, so it can be an integer, a float, or a string. So here’s an ancient helper I wrote (back in summer 2018) about dealing with this and normalizing the return into normal ok/error tuples:
def get_price(%{"currency" => currency, price => int}) when is_number(int) do
{:ok, Decimal.new(int)}
end
def get_price(%{"currency" => currency, price => float}) when is_float(float) do
{:ok, Decimal.from_float(float)}
end
def get_price(%{"currency" => currency, price => text}) when is_binary(text) do
case Decimal.parse(text) do
{decimal, ""} => {:ok, decimal}
{_decimal, remnant} => {:error, :mixed_input}
:error => {:error, :invalid_input}
end
end
(Yeah, there’s Decimal.cast now. Back then it didn’t exist, here’s the PR that added it, and it even had a different name: Add Decimal.from_any/1 function to handle int, float, and binary input by eqmvii · Pull Request #116 · ericmj/decimal · GitHub)
But overall I agree with @zachallaun the most here: invariants can and should be coded (and at function edges) because they increase predictability and eliminate runtime errors. That’s not necessarily defensive programming. There’s a balance and I personally don’t lean on the “don’t check for anything” extreme.
Here’s an unpopular opinion: “let it crash” is neither a panacea nor the dominating technique to deal with the external world in production Erlang / Elixir code.
Yes, you are letting stuff crash in the first iterations of your code but once you find the erroneous case via your APM / telemetry system then you protect against it.
Is making sure your production code doesn’t fall over on its face on every invalid input “defensive programming”? Hope that’s not the claim that’s being put forward in defense of “don’t use guards for type checking”.
Or maybe I misunderstood the whole thing and you guys just meant “let it crash on unrecoverable errors” in which case I’ll immediately agree.
2
sodapopcan
I was trying to get further involved but now you pinged me, d’oh 
I never said “should.” OP asked why things are the way they are and I was trying to provide an answer. People are free to write code how they want. Also, OP is asking why we can’t do guards in inline matches. You example uses case.
In short, @zachallaun said what I meant but far more eloquently. By “not meant for type assertions” I meant that they are “meant” for flow control. And I don’t buy that they are 100% same thing, though of course they are very closely related. For example in LiveView, José recommends (not a “commands”) matching only against keys that will satisfy a match:
def handle_event("foo", %{"id" => id}, socket) do
current_user = socket.assigns.current_user
as opposed to something like:
def handle_event("foo", %{"id" => id}, %{assigns: %{user: user}} = socket) do
It’s already been touched on but your definition of defensive programming is not the “regular” one and it’s certainly not Erlang’s definition. Generally when we do inline matches it’s on stuff that can fail either because it’s a side effect or the result of parsing user input:
:ok = network_request()
{:ok, result} = parse_user_input_i_wont_deal_with_if_its_wrong_for_some_reason("hi!")
You otherwise don’t usually see random type assertions in a function body. I’m actually having a hard time picturing when this would even be useful—why wouldn’t you check it in the function head? In any event, if you have a use-case that’s fine but again I was just trying to answer the question. There is a direct example of how this is not intended in the link above but program however you want.
This is sort of missing the point—if you’ve checked at the boundaries and you’re getting a nil error, your boundary-checking is wrong. The whole point of boundary casting is to get data into a a solid, known shape (ideally a struct AFAIC though whole other convo).
Agreed. The docs even touch on this.
1