Type system updates: moving from research into development

The problem here is that both exhaustive and non-exhaustive matching are useful and people will want to use both not just in the same project, but even within the same module.

I quite like the case and case! idea, with the exception that, as stated above, their behaviour would have to be the opposite of what people would expect based on the rest of the language.

I’m not sure how to deal with matching in function heads, though. def and def! seem like the obvious choice, but I really think the exhaustive/non-exhaustive decision should be made at the call site, not in the function definition.

This ties in back to Jose’s earlier example:

def foo_or_bar(:foo), do: ...
def foo_or_bar(:bar), do: ...

Most of the time, we probably want the type checker to be strict and allow only the two valid atoms, but maybe in the situation Jose described - foo_or_bar(String.to_existing_atom(string)) - we would rather tell the compiler to trust us (and let the runtime raise if the input is invalid) than explicitly check the value and raise manually in order to satisfy the strict checker.

3 Likes