Next up for patterns: type patterns in switch

[Brian Goetz]

> P.S. Well, not exactly.  You didn’t expect *no* comment from me? :-)

There's always one ....

> It is slightly premature to completely outlaw `x instanceof 42`,
> because of nulls:  You can replace that with `x == 42` only if `x`
> is `int`.  With strings, identity is also a problem; `x instanceof "foo"`
> does not replace with an `==` expression.  In the end, if we outlaw
> `x instanceof 42` the workaround might be `Objects.equals(x,42)`
> but that incurs boxing overhead if `x` happens to be a primitive.
> So, I think the fate of `EXPR instanceof CON_PAT` is up for grabs.
> That said, I’m fine with leaving it out for starters; it can be added
> after further thought—or not.

Truth be told, I am hoping we can avoid doing constant patterns 
entirely.  The obvious denotation (a literal) leads to at least the 
appearance of ambiguity -- when a user looks at `foo(0)`, they can't 
immediately tell whether the 0 is a parameter or a nested pattern (and 
worse when patterns have parameters.)

In instanceof, we can avoid them entirely by unrolling into

     if (x instanceof Foo(var y) && y == 0) { ... }

which is more flexible anyway because we can have not only equality 
constraints, but comparison constraints, etc.  If we have guards, we can 
do the same with cases:

     case Foo(var y) where y == 0

So it's not clear whether we need constant patterns _at all_, except as 
far as it looks like existing switches are full of constant patterns.  
But maybe that's really just a funny form of case label....