possible bug with instanceof pattern matching

[Brian Goetz]

Correct.  In your second example, neither JE is in scope.  The simple 
rule about pattern scoping is that a pattern variable is in scope where 
it would be definitely assigned.  (The definite assignment rules look 
complicated in the spec, but they are the obvious rules of "I couldn't 
get here without having been through here first" that we all run when we 
simulate Java code in our heads.)  So in

     if (x instanceof Foo f || x instanceof Bar b) { ... }

neither f nor b are in scope inside the block, because neither is 
definitely assigned when we get to the block.  (We may know that one of 
the two patterns matched if we get into the block (in fact, exactly 
one), but because we have no idea which one, we cannot conclude that 
either pattern variable is definitely assigned.)

On 2/19/2024 1:19 AM, Charles wrote:
> Hi Brian
>
> Thanks for clarifying. I suppose the second case, which uses two 
> separate variables, is also explained by that.
>
> Since pattern matching doesn't differentiate which "je" got created, 
> it can't tell which variable will eventually be visible in the scope. 
> Hence it is saying both variables are not visible in the scope.
>
>
>
>
> and as always, have a great day
> *
> *
> *Best Regards
> *
> *Charles*
> *
> *
>
>
>
>
> On Sun, Feb 18, 2024 at 11:33 PM Brian Goetz <brian.goetz at oracle.com> 
> wrote:
>
>     This is not a bug; this potential feature was discussed at some
>     length during the design process.  Another way this
>     potential-feature could show up is:
>
>         switch (container) {
>             case Box(String s), Bag(String s): ... use s ...
>         }
>
>     The reason that we chose not to proceed with such "binding
>     merging" is that when you get inside the block, `je` is one
>     variable with two declarations; you don't really know where the
>     declaration is.  (So IDE navigations like "go to declaration"
>     would have to learn to highlight TWO (or more) declarations, for
>     example.)
>
>     This feature isn't fundamentally impossible, and we could consider
>     it again in the future, but it was a deliberate decision to not go
>     this far at this time.
>
>
>     On 2/18/2024 6:53 AM, Charles wrote:
>>     Hi all
>>
>>
>>     What I'm about to report below is *openjdk 17*.
>>
>>
>>     This doesn't compile
>>
>>     if (ex instanceof JedisException je
>>                                 || (ex instanceof ExecutionException
>>     ee && ee.getCause() instanceof JedisException je)
>>                 ){
>>        ... blah blah
>>     }
>>
>>     reason being the second je is already defined in the scope.
>>     image.png
>>
>>     if you think about it. if ex is je, then, the second part won't
>>     trigger. And if the second part is reached, then ex is not je.
>>     Hence there is only going to be one statement mapped to je.
>>     no confusion here. I feel this should be allowed.
>>
>>
>>     Let's assume the above is the way it should be. I use different
>>     names for the second variable.
>>
>>      if (ex instanceof JedisException je
>>           || (ex instanceof ExecutionException ee && ee.getCause()
>>     instanceof JedisException second_je)
>>                 ) {
>>     log.error(je);
>>     log.error(second_je);
>>                 }
>>
>>     image.png
>>     This still doesn't compile.
>>
>>     I would like to bring this issue up for discussion.
>>
>>
>>
>>
>>     and as always, have a great day
>>     *
>>     *
>>     *Best Regards
>>     *
>>     *Charles*
>>     *
>>     *
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240219/8cf3ec9a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 37408 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240219/8cf3ec9a/image-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 33303 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240219/8cf3ec9a/image-0003.png>