Explain flow scoping for instanceof pattern variables. Where is the binding variable in scope, and why does it work after && but not after ||?

## What flow scoping is Most variables in Java have **lexical scope**: they are visible inside the `{ }` block where they are declared, period. A **pattern variable** introduced by `instanceof` is different — it has **flow scoping**. It is in scope only at the program points where the compiler can *prove*, by analyzing control flow, that the instanceof match succeeded (and therefore the variable was definitely assigned). If the compiler cannot prove the match held, the variable is simply not in scope there and referencing it is a compile error. Think of it as: "the binding exists wherever the test is guaranteed-true." ## The `&&` case (in scope) The `&&` operator short-circuits: its right operand is evaluated **only if the left operand was true**. ```java if (obj instanceof String s && s.length() > 5) { ... } ``` When Java reaches `s.length()`, the left side `obj instanceof String s` must have been true — otherwise `&&` would have short-circuited and skipped the right side. So at that point `s` is guaranteed to be a bound String, and it's in scope. It is also in scope in the `if` body, for the same reason. ## The `||` case (NOT in scope) The `||` operator short-circuits the opposite way: its right operand is evaluated **only if the left operand was false**. ```java if (obj instanceof String s || s.isEmpty()) { ... } // COMPILE ERROR ``` When Java would reach `s.isEmpty()`, the left side was *false* — meaning `obj` was not a String and `s` was never bound. The variable doesn't exist there, so the compiler rejects it. This is not an arbitrary rule; it's a direct consequence of "the binding exists only where the match is guaranteed true." ## The negated early-return case (in scope after the if) Flow scoping also reaches *past* an `if` when the false branch leaves the enclosing scope: ```java static int len(Object obj) { if (!(obj instanceof String s)) { return -1; // bail out when NOT a String } return s.length(); // s is in scope here! } ``` The only way to reach the line after the `if` is for `!(... instanceof String s)` to be false — i.e. the match succeeded. So `s` is definitely bound from that point on, and it's in scope for the rest of the method. This is the idiomatic 'guard clause' style for patterns. The same applies with `throw`, `break`, or `continue` in the false branch. ## Why the compiler can do this Flow scoping uses the same **definite-assignment / reachability analysis** the Java compiler already performs (the analysis that, e.g., rejects reading a local before it's assigned). The compiler tracks, at each program point, whether the pattern variable is "definitely matched." ## A consequence: pattern variables can shadow / coexist Because a pattern variable's scope is precisely the matched region, you can reuse the same name in mutually exclusive branches, and a variable that is out of scope in one path doesn't conflict with one in another. ## Terms recap - **Lexical scope**: visibility tied to enclosing braces. - **Flow scoping**: visibility tied to where the match is provably true. - **Short-circuit**: `&&` skips the right side if left is false; `||` skips the right side if left is true. - **Definite assignment**: the compiler's proof that a variable has a value before it's read.