[External] : Re: Primitive type patterns

[Brian Goetz]

This is a valid generalized preference (and surely no one is going to 
say "no, I prefer to play to our weaknesses.")  But at root, I think 
what you are saying is that you would prefer that pattern matching 
simply be a much smaller and less fundamental feature than what is being 
discussed here.  And again, while I think that's a valid preference, I 
think the basis of your preference is that it is "simpler", but I do not 
think it actually delivers the simplicity dividend you are hoping for, 
because there will be subtle mismatches that impede composition and 
refactoring (e.g., new "null gates" and "box gates".)

In any case, it's clear that nearly everything about the way we've 
designed pattern matching is "not how you would have done it"; you don't 
like the totality, exhaustiveness, error handling, and conversion 
rules.  And that's fine, but I think we're spending too much effort on 
"I wish there were a different design center".  What I'd like to get 
feedback on is:

  - Is there anything *specifically wrong* with what is being proposed?  
Did I extrapolate incorrectly from the rules for assignment conversion, 
for example?
  - How can we come to a better way of presenting the material, so that 
people don't fall into the same pothole regarding "pattern matching 
means different things in different places", for example?

Would also like to hear from other people....

> I think we should play on our strengths, destructuring instead of 
> unboxing, pattern methods instead of primitive conversions + rangecheck.
> I prefer to have a few small well defined patterns (type pattern, type 
> destructuring, pattern method) each with a simple semantics (so keep 
> the type pattern to be about subtyping relationship only) and draw 
> power from the ability to compose them instead of having patterns with 
> a huge semantic baggage (type pattern with the assignment semantics) 
> and the corner cases that come with it.
>
> We may still need assignment conversions when we mix pattern and 
> assignment, but because we want to be "backward compatibility" with 
> the simple assignment semantics.
>