I could imagine solving this by tagging the function.
woylie
christhekeele
My interpretation was that case! would the new behaviour, to be backwards-compatible. I definitely would want a new keyword for the new type-exhaustive pattern match.
I do see how ! connotations with “may fail” would make an argument for the non-exhaustive version. In this situation I’d rather a keyword like handle, with language that asserts that it can handle all cases, in addition to case, which simply describes all the cases you wish to handle.
So something like:
handle File.read("foo") do
{:ok, contents} -> contents
{:error, :enoent}} -> nil
end
Would raise a
CompileErrror: did not handle all cases, missing:
{:error, :eacces}
etc
Whereas
handle File.read("foo") do
{:ok, contents} -> contents
{:error, _}} -> nil
end
would compile.
5
tcoopman
Interesting discussions to read.
One solution to the discussion I’ve not seen yet is making errors/exceptions explicit in type expressions.
If you could say that a functions return value is :ok | Exception then you don’t need your exhaustiveness check on case and doing :ok = Foo.maybe_fail!() would all be ok.
On the other hand if you didn’t annotate your function with a possible exception the compiler would complain
This probably opens an other can of worms but it still might be interesting to explore.
(And it’s probably something the people working on this have already thought/discussed about. It’s a bit funny there’s an announcement about first step and we go into a full what if discussion 
)
4
dimitarvp
I suppose something like case! is inevitable but I am still afraid it would splinter the community. Hopefully I am wrong.
0
christhekeele
This is possible in typespecs today, with the no_return() type.
Libraries and applications used to use exactly something like :ok | no_return() for functions they intended to indicate would explicitly raise an error in certain circumstances, to hint to the caller that they may need to handle something.
Sadly, since Elixir 1.15 the standard library docs recommend against this. This is very confusing to me, especially as Elixir explores an exhaustive type system where there would be a meaningful difference in code that, like any function, could always potentially raise an exception; and functions specified as potentially raising an exception you might need to exhaustively handle to ensure correctness.
I’d much rather see no_return() come back, with support for annotating a function with something like no_return(File.Error), and have an exhaustive type checking system that ensures that callers to functions annotated with no_return() are inside a corresponding try; rescue e -> handler, and functions annotated with no_return(struct) are inside a corresponding try; rescue struct -> handler.
0
tcoopman
In my opinion no_return as a successful call, for side effects, similar to void or unit in other languages is something entirely different than this function could throw an exception. Exception means something didn’t go correctly.
So the type annotation could be: no_return | Exception for example in the case of File.write!
2
josevalim
Creator of Elixir
We recommending against no_return() is specific to Dialyzer, as it makes it less useful as it will avoid warning when it finds some error cases. It has no relation to how exceptions will be handled in the type system.
2
christhekeele
That makes sense to me. I suppose it was frustrating to read as a library author who wants to indicate when I want a caller to know I may intend to raise based on their input. But of course, with a supportive type system, I would have a mechanism to do so.
0
zacky1972
Creator of Pelemay
D4no0
I think treating exceptions not as data is a mistake, in this case exceptions were implemented in this manner to be able to be passed up the process tree, however this design makes functions not pure by design (be the function with side effects or not).
1