RFR: JDK-8231826: Implement javac changes for pattern matching for instanceof

[Jan Lahoda]

On 10. 10. 19 17:48, Brian Goetz wrote:
>>>> As far as I know, there is one (significant) open issue in the spec, and that is whether non-reifiable types should be allowed in "instanceof <type-test-pattern>". Currently (AFAIK), the spec does not allow non-reifiable types in the type test pattern in instanceof, and the javac implementation should be consistent with the spec. Should the spec change, the corresponding update to the javac code should have a very limited impact.
> 
> To be clear, do we treat `instanceof T` and `instanceof T t` differently, or do we disallow non-reifiable types in both places?  If the latter, I am fine to say that this is an enhancement that can come in later phases of PM.  The former is a little more worrisome, because I would expect users to be confused by an asymmetric treatment.

I believe the current spec treats them consistently, and without a 
change from the original state, i.e. non-reifiable types are prohibited 
for both ordinary instanceof and pattern matching instanceof. The javac 
patch/behavior should be consistent with that(*).

Jan

(*) The behavior of javac using the patch submitted herein should be 
consistent with the spec. The patterns-stage-1 branch in the amber repo 
is not (at least not yet). That branch is missing quite a few recent 
updates that are in the patch submitted here, as many of them depend on 
the new preview feature API handling. The branch should be ignored for now.

> 
> 
>> * looking at the spec, it seems like both "instanceof T" and "instanceof T t" are cases of type test patterns.
> 
> This is true, though I suspect that ultimately we’ll have to refine the spec somewhat.  When we get to patterns in switch, or nested patterns, I think having `T` be a pattern will lead to amibiguties with constant patterns, and we’ll end up making the grammar a little more complicated in order to clean this up.  But, for now, the spec treats them the same, and there’s some good in that too.
> 
>