Pattern matching -- background and design goals

[mark]

On 2017-04-22T15:04:20 -0400
Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> 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."

Yeah, that's the spooky part. I have a strong preference for simple
lexical scoping, but I'll suspend any disbelief until I can play with
an implementation.

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

Got it.

I think it'd be slightly tragic if Optional couldn't get exhaustiveness
in some form eventually. I mean in languages like Kotlin and Scala (as
you're probably well aware) Option{al} is sort of intended to subsume
nullable references for the purposes of correctness ("You're prevented
from failing to check for a missing value"). It's pretty much ADTs 101,
so it'd be sad if Java suddenly got pattern matching and exhaustiveness
checks but ended up with an Optional that couldn't make good use of
them.

M