Quick question regarding pattern matching

[org.openjdk at io7m.com]

Hello!

On 2017-03-23T10:32:16 -0400
Brian Goetz <brian.goetz at oracle.com> wrote:

> Without getting into the details -- I'd like to wait until a Patterns 
> JEP is proposed before doing so -- I'll give some quick overview answers.

Yes, I appreciate the desire to wait for a JEP!

> 1.  Yes, exhaustiveness is important.  The obvious tool there is 
> sealing, and sealed classes at the language level would really also like 
> sealing support at the VM level, which can be considered a 
> generalization of finality.  (Though, even with sealing at both the 
> language and VM level, there is still a possibility of being surprised 
> by separate compilation artifacts, since if the switch is in a different 
> class than the one in which the supposedly-sealed hierarchy is defined, 
> new subtypes can still be added, and if the client is not recompiled, 
> you will get a surprise.)  Stay tuned.

Good to know, thanks. I had a feeling that the nestmates proposal would
be involved (from our conversation on the valhalla list a while back).

As far as I can tell, current matching implementations in languages
handle the binary incompatibility case you mentioned by synthesizing
bytecode that raises an unchecked exception such as MatchException as a
fallback. I don't think I covered this specifically in that article I
wrote[0] but it's fairly apparent from the bytecode samples. 

> 2.  We try :)  There are likely to be VM-level building blocks that 
> multiple languages can build on, and sealing is a good example.  That 
> said, any given VM feature isn't always ideal for every language.  The 
> balance we try to strike is: try to identify the right VM primitives 
> that are useful to as broad a selection of languages as possible -- but 
> don't get caught up in trying to design a grand unified theory, as 
> that's not the primary goal. (Default methods are a good example; 
> they're useful to a lot of languages, but some languages may choose not 
> to use them as a trait substrate because they want different conflict 
> resolution semantics.  And that's OK.)

Right!

I think it's important to keep in mind that algebraic data types aren't
necessarily value types (if value type is taken to mean all-immutable
fields with no identity) so it's nice to be able to keep the discussion
somewhat separate from the Valhalla work via Amber. Just being able to
give Scala and Kotlin the few sealing primitives they need instead of
having to rely on proprietary annotations would go a long way towards
improving matters, I think.

M

[0] http://io7m.com/documents/adt-jvm/