Having digested both this and the switch document, I'm slightly disappointed in that I can't find much to which I object. :)
Patience! I'm sure I'll come up with something objectionable eventually.
The new scoping rules are a little spooky with regards to reading comprehension, but I think they're a fairly pragmatic choice in the absence of "let" expressions in the language.
The secret to understanding these rules is that they are the definite-assignment rules in disguise. They basically say that a binding variable is made-available-to any expression / statement in which it would be definitely assigned. The weird thing about them is that they don't conform to traditional block scoping; the set of expressions/statements into which a given pattern may inject bindings does not form a traditional block. You could call this "flow-based scoping."
I'm curious though, based on the given Optional example, if the intention is to design things in such a way that values of the existing Optional class could be matched upon (with exhaustiveness checks) without anyone having edited the definition of Optional?
Not quite. But it doesn't require deep intrusion (like changing the implementation to a Some/None decomposition); merely the adding of matchers (which I claim are some sort of class member, so this is like adding new methods) for Optional.of() and Optional.empty(). What that doesn't give us is exhaustiveness -- but at least it gives us a path to back-fitting existing classes with ctors/factories to play in destructuring-land without major surgery.
