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.
