[patterns] reconsidering how the created variable name binds

[Reinier Zwitserloot]

On Sun, 29 Dec 2019 at 20:56, Brian Goetz <brian.goetz at oracle.com> wrote:

>
> In general, before we get into "proposals", it is generally good to back
> up and talk about what _problem_ we are trying to solve.


The problem is that the case I'm trying to avoid is extremely similar to a
case that consensus seems to indicate should be catered to:

    if (!(x instanceof Point p)) return;
    // p should be available here

whereas Tagir's case is the exact same thing, except instead of 'return'
it's a bunch of code that is clearly an endless loop, but whether it is an
endless loop specifically according to DA rules is unclear. Unless we're
willing to make an exception and state that the DA endless loop rule does
not apply here, OR try to solve it in a sideways fashion by disallowing
shadowing, I don't think it can be fixed (and both of these solutions don't
seem like a good idea).

Nevermind, in other words.

The notion of "within the lexical context in which it is created" is
> also problematic, as this is _too broad_ a scope; in the following, you
> wouldn't want `x` to be in scope at `A`:
>
>      if (A && foo instanceof String x) { ... }
>
>
Given that the current draft spec is catering to important use cases this
is probably a moot point, but... Why not? This:

    int a = a;

means that the second 'a' refers to the first 'a' (and does not  compile
because the usage of the second a is in a context where DA says it is not
definitely assigned. In fact, 'int a = a = 5;' is legal and compiles).

Seems like the same chicken-and-egg situation, solved in the same way: the
variable is bound, but because it is not definitely assigned, cannot be
used.

OK, I'll agree on the unfortunate part.  But I'm not there on "so we
> have to change something" yet.


I agree; I don't think this reaches the level of 'cant ship like this'.


<< refactoring robustness is a core part of the design >>
>


Should I be able to refactor this:

    if (!(z instanceof Integer i)) throw new IllegalStateException();
    //use i here

to this:

   switch (z) {
        case Integer i: break;
        default: throw new IllegalStateException();
    }

    // use i here

That obviously won't work, as switch introduces mandatory scope.

Normally in refactor scripts, the refactor script will occasionally
'escape' the local variable declaration in order to make scoping rules
work, i.e. some construct of the form of `int i = 10;` is broken apart by
the refactor into `int i;`, showing up above some introduced scope, and `i
= 10;` showing up inside it. I don't think that's possible with the pattern
match construct.

I guess that means it's just 'robust under refactorings that do not
introduce new scopes', but presumably most refactorings fit that particular
description, and catering to the few refactorings that do isn't worthwhile.