This clarifies some stuff for me, thanks! Well, other comments have too but this is a nice summary.
Well, unless this is true, of course 
sodapopcan
sabiwara
Elixir Core Team
So the argument is that
_ -> ???is making things strictly more verbose for no added benefit. If you want to better communicate, then using:bar -> ???is better.
OK sorry for adding confusion, I had the wrong premise which was that this was meant to be used instead of case!, not in conjunction 
Absolutely. I witnessed something very similar many years ago when people were very happliy doing
catch (Exception e) { ... }in Java. And that achieved only one thing – it masked bugs.
I totally understand the rationale, but just wanted to point out that if we go with case!, the same thing will be said of plain case (just like today). It wouldn’t completely “mask bugs” since it still raises, but the compiler loses its ability to check for exhaustiveness.
Just playing the devil’s advocate here for a bit, if we compare these two:
case/case!to opt-out/in of exhaustiveness, pokemon clauses forbidden- just
case, pokemon clause allowed as the way to opt-out exhaustiveness (my original misunderstanding)
Both allow opting out, and opting out will be needed anyway in some cases, so this doesn’t distinguish them. The real differences would be:
- is more compact and writes less code when opting out
- is not without merit either:
- we only need to introduce one thing,
???, and it behaves consistently - would also work for function heads (no need for
def!,defp!…) - opting-out is noisier/uglier than keeping the check => easier to notice, stronger deterring effect
Or should we introduce =!? (just kidding).
More seriously, having a warning here would really ruin =/2 in most cases and prevent the kind of idiomatic elixir that was being advocated for here (already posted above). That’s a tricky one.
Oh to be fair I was merely quoting Jose in the first place 
adw632
Could this API/module versioning conundrum of being damned either way, not be handled by a (custom) guard based on a module version (@vsn) attribute?
Could a custom guard match the version requirement/constraint against the module @vsn attribute?
Basing the guard on SomeModule.__info__(:attributes)[:vsn] and potentially if using semantic versioning, test the guard version constraint using Version.match?
I am certain you could come up with a much cleaner built in way of guarding both functions and clauses based on code evolution concerns like module versions in a way that the compiler type system understands so as to handle API version constraints intelligently (i.e. so as to not complain about impossible cases when compiling against the older/newer version of a module).
It does beg the question would an idealised utopian type checker check against all possible combinations of versions expressed in the code where such constraints are specified?
Whilst this utopian approach is infeasible due to combinatorial explosion, it does demonstrate that there are some in principle practical limits that we can only really be type checking against the exact versions we are actually compiling against and that there will exist combinations of versions where warnings may appear for some, but not for others as we don’t all move every dependency in our code base forward in lock step.
I do think the API/module versioning / code evolution concern does require some delicate consideration because it’s right at the heart of the design time checking problems that we do want to know about with the type system. We do want that heads up that we are using a return value that is not possible, due to a typo or no longer present (API evolution), and we do want to know about missing possible values so as to handle them explicitly, whilst also detecting and driving out bad / overspecifiied / defensive catchall/pokemon clauses that occlude future code evolution problems.
erszcz
This is quite a well-known wisdom in communities using languages with exhaustiveness checking. See Yaron Minsky’s talk “Effective ML” - he talks about catch-all patterns, exhaustiveness, and code evolution over time at 28 minutes into the video: Jane Street Blog - Effective ML video
BTW, this material is from 2010!
With a type checker a few more of the techniques he describes there would be possible in Elixir (or Erlang), or at least enforceable at compile time.