Flow scoping

[Brian Goetz]

> Before we get to the harder ones, can people share what made them uncomfortable, for the ones where you marked "not comfortable with the answer”?

We’re currently exploring the consequences of Doug’s query about introducing non-conditional locals into expressions (not necessarily because we want to have such a feature now, but because if we did want such a feature, we’d want the scoping machinery to handle it well, and if it doesn’t, that may suggest refinements for the scoping machinery.)  

Let’s talk about the more complicated examples in the quiz.  

Everyone seemed to do pretty well on the if/else ones (flip the condition, and it flips the scopes), the conditional-expression ones, and  the short-circuiting examples.  Let’s talk about merging.  

In this example:

```
public void test() {
    if (a instanceof String v || b instanceof String v) { 
        println(v.length());
    }
    else {
        println("foo");
    }
}
```

we have two candidate conditional variables called `v` of type `String`, and the flow rules ensure that at any point, at most one of them could be DA.  So in the `true` arm, the use of `v` is OK, and it binds to whichever of these is DA (both must have the same type, otherwise its an error.)  The rules sound complicated, but as always, our DA intuition guides us pretty well — we can’t get to the `true` arm unless exactly one of the `instanceof` expressions has matched.  

In the `&&` version of this example, people’s intuition was mostly right — that this code is illegal — but some were unsure: 

```
public void test() {
    if (a instanceof String v && b instanceof String v) { 
        println(v.length());
    }
    else {
        println("foo");
    }
}
```

The answer here is that because `v` is not DU in the second `instanceof`, and therefore might be in scope, this constitutes an illegal shadowing, and the compiler rejects it.

The hard ones (and the potentially controversial ones) were the last two — regarding use _after_ the declaring statement:

```
public void test() {
    if (!(a instanceof String v)) 
        throw new NotAStringException("a");
    if (v.length() == 0)
        throw new EmptyStringException();
        
    println(v.length());
}
```

```
public void test() {
    if (!(a instanceof String v)) 
        return;
        
    println(v.length());
}
```

In both of these cases, flow scoping allows `v` to be in scope in the last line — because `v` is DA at the point of use.  And this is because if the `insteanceof` does not match, control does not make it to the use.  In other words, we can use the full flow analysis — including reachability — to conclude the only way we could reach the use is if the binding is defined.  (If there was not a return or a throw, then the last use would not be in scope.)  

For some, this is uncomfortable at first, as not only does the scope bleed into the full `if` statement, but it bleeds out of it too.  But again, we’re driven by two goals:

 - Make scoping line up with DA-ness (so we can build on an existing mechanism rather than creating a new one)
 - Be friendly to refactoring.  

In the latter point, I’d like for

    if (E) { throw; } else { s }

to be refactorable to

    if (E) throw; s;

as it is common that users will perform precondition checking on entry to a method, throw if there’s a failure, and then “fall” into the main body of the method:

    if (!(a instanceof String s))
        throw new IllegalARgumentException(a.toString());

    // use s here

The main argument against supporting this is discomfort; it feels new and different.  (But, because we’re building on DA, it’s not, really.)