Comment on JEP 305

[Brian Goetz]

> Specifically, I want to share my feedback regarding the "Pattern Matching for instanceof" feature.

Actually, your feedback is not on the feature, but on the stewardship 
process itself -- you wish we had done a different feature instead.  
Which is a valid reaction -- everyone has their own preferences for what 
we should do -- but unless you are the first person to suggest "have you 
considered flow typing" (for which you would be many years late), such 
feedback is not all that helpful.  We looked carefully at flow typing, 
and found it wanting.

Tagir well-covered the two main reasons why flow typing is a poor 
alternative to pattern matching:

   - Adding flow typing to the language could change the meaning of 
(that is to say, break) existing code;
   - Flow typing is a much weaker and less general feature than pattern 
matching; it's just not obvious from reading JEP 305, because this is 
merely the first installment of pattern matching and so many of the 
examples look like they could be addressed by flow typing.

The question of "why not 'just' do flow typing" was also addressed in 
the public document:

http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html

Flow typing is not a _bad_ feature, but it's a pretty weak one; it 
basically works only for one thing.  When you fold in the compatibility 
risk, that's a pretty automatic no.

> There is no reason given for why the variable should be renamed

There are several misconceptions buried in this claim.  First, that it 
is a renaming at all; it is not, it is the declaration of a new 
variable, with its own scope (and mutability).  But more importantly, 
the operand of an instanceof expression (or a switch) need not be a 
_variable_; it can be any expression.  You're letting the "Flow typing 
is all I will ever need" concept prevent you from understanding what 
pattern matching actually is.

As to your main gripe -- having to come up with a new variable name -- 
it has been (publicly) discussed that the binding variable in a type 
pattern at the top level of an instanceof/switch whose operand is a 
variable declare a variable name _could be_ the same as the operand:

     if (x instanceof Foo x) { ... }

where the inner `x` would shadow the outer.  This is a possible future 
enhancement -- there's nothing intrinsically wrong with it -- but if you 
look at the parade of qualifiers I had to add to my description above, 
you get an inkling of why this isn't something we'd grab at out of the gate.