Sure, but this is exactly the kind of defensive programming people like not having to do in Elixir. Enforcing this would not just break most of existing code, but also fundamentally change the idiomatic way to use the language.
Sorc96
dimitarvp
- You are kind of generalizing. I have already seen people here (whom I respect a lot as professionals) say their work will be improved by having the stricter typing style. So obviously not everyone is on the same opinion.
- I don’t think anyone is talking about truly enforcing things. Let’s remember that Jose said this will be (a) gradual roll-out and (b) that it will be ultimately opt-in. I don’t think there would be any breakage.
- If we’re talking production systems you will eventually have to put in the above defensive clause anyway because at one point, inevitably, you’ll get non-sanitized input. So you seem to be arguing against having to put this code in upfront vs. putting it in later. It’s inevitable that it will be put in however.
1
Sorc96
I definitely agree that a stricter type checker could be benefitial, and of course, user input needs to be sanitized. But at the same time this strictness could lead to a lot of boilerplate and force people to manually write catch-all clauses that raise an error, which is what the runtime already does on its own.
That’s why I think it may be necessary to support both options in order to keep Elixir’s expressivity and backwards compatibility with existing code.
0
dimitarvp
Sorc96
Yeah, I don’t think we disagree nearly as much as it may seem. The internet is just good at amplifying that feeling 
2
josevalim
Creator of Elixir
Why do you think that’s the case? We use File.read! when you know it can fail for other reasons but we would rather raise at runtime than handling it. case! is used when you know it can fail for other reasons but we would rather raise at runtime than handling it. Perhaps you are seeing it from another angle?
3
woylie
The other angle is probably: case! would not raise at compile time if you miss a pattern, but case would raise at compile time, and from that perspective, it is counterintuitive. Maybe we’re mixing semantics here, since usually, as you pointed out, the ! is for runtime behaviour, but in the case of case/case!, we’re actually modifying compile time behaviour. Only that in the case of case, this changed compile time behaviour prevents certain situations from occurring at run time then.
5
josevalim
Creator of Elixir
I see. I would add that type violations will definitely start as warnings, so there would be no raising at compile-time either way.
1
wanton7
I was thinking that as well. I mean case would catch errors during compile time, and case! wouldn’t and allow it to crash at runtime. How would that be the wrong way around? But since I don’t use Elixir professionally, maybe I had misunderstood something. Thanks for confirming that was not the case.
0