Pattern matching -- background and design goals

[Brian Goetz]

> 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.