Even _ -> nil would be fine, exhaustive pattern matching means that a clause will always match and you will never get a runtime error there. Of course, it’s up to you to propagate the error up or manually raise. This would make it more tedious to handle errors and it would remove part of the magic of quickly developing in Elixir.
Sorc96
5
sodapopcan
Now I gotcha, thanks!
I agree though this is why I am intrigued by the prospect of case! as it would allow you to opt-in.
2
Sorc96
I agree, I don’t really see another way to reconcile these two opposing points of view other than letting the programmer choose which one they want.
Although, maybe there could be an argument for making case always exhaustive (still, it would break existing code), while pattern matching in function heads and single line matching like our File example would allow non-exhaustive matches, since that is how people seem to use these slightly different mechanisms.
1
LostKobrakai
I don’t think that’s the differenciator. Single line is just the “I want to handle 1 case” vs. a non exhaustive case is the “I want to handle n out of m cases”.
1
dimitarvp
Mostly yes but again, if you can only expect :ok / :error tuples then just matching {:ok, value} and {:error, reason} is still exhaustive pattern-matching even if you don’t handle the N possible error cases.
1
Sorc96
That’s true. I’m just going with what I’ve realistically seen in the code that I’ve read and maybe this would be an acceptable trade off? Single line matching is super common, while case usually seems to be meant to be exhaustive. And if not, either handling the error explicitly or extracting the case into a helper function with multiple heads could be good enough.
2
aiwaiwa
Curious if you are borrowing any ideas from Gleam, it’s kinda neat syntax-wise and not cluttered and easy to read.
1
sodapopcan
It honestly never occurred to me to make case non-exhaustive until the other day (I just didn’t have the vocabulary to describe it), hence my curiosity here. Is a bare {:ok, contents} = File.read("...") really that common, though? That’s what File.read! is for. If those types of things could be prevented I’d be pretty into that, though not at the expense of now having to type everything to get it. I have very little experience with statically-typed languages (mostly OCaml) so I don’t really know what I’m talking about. I share a bit of @D4no0’s concerns but also share their optimism. It’s clear that types are what (most of?) the people want and intense diligence is being exercised here, so I’m mostly optimistic!
3
Sorc96
Of course, there is probably no reason not to use File.read! if we’re expecting it to succeed. I still think that single line matches to assert success are pretty common, though. Maybe that wouldn’t be the case if there was always a bang version of every function than can fail. But even that would only solve :ok | :error situations and nothing else.
This reminds me of a thought I had some time ago. Since bang functions are pretty much always implemented the same way, how awesome would it be if ! was a macro, so that you could use it with any function and nobody would ever need to explicitly implement a bang version of a function again? It would basically be like an option unwrap function, but in one character. But that’s definitely a topic for another discussion.
5
zachallaun
José, do you know whether the initial development work for this will be “in the open,” or do y’all plan to keep development private until some internal milestone is reached?
Selfishly, I hope that work is just done in a branch of elixir-lang/elixir, but I can understand how that might lead to a “too many cooks in the kitchen” scenario, or people trying/expecting/assuming things of the implementation while it’s still in a very much underdeveloped state.
0