Essentially, you're saying that if someone declares a pattern variable
that would shadow a DU (final, please!) local, then the variables are
merged and the scope is pinned at the scope of the local. That's nice
in that the scope and declaration point are now clearer, but on the
other hand the concept of binding is now muddier: pattern variables now
interact with shadowing, with locals, and maybe get sucked into
mutability too ("why not just treat binding as ordinary local
assignment".) So it plugs one leak, but opens up several others.
On 1/8/2019 5:55 PM, John Rose wrote:
On Jan 4, 2019, at 6:07 AM, Tagir Valeev <amae...@gmail.com
<mailto:amae...@gmail.com>> wrote:
For the record: I heavily support this. If then-branch cannot
complete normally, then unwrapping the else-branch should preserve
the program semantics. It works today, and it should work in future
Java as well.
I agree also. But it is uncomfortable that the binding of the flow-scoped
variable gets buried in a place that is harder to spot.
Here's a possible compromise: Allow flow-scoped variables to leak
out the bottom of a statement, but only if they are predeclared before
the statement, in the parent block. They would be predeclared blank.
Example:
preconditions();
if (mist() && shadow() && !(x instanceof String s))
throw q;
else {
manyLinesOfStuff();
println(s); // s obscured by mist and shadow
}
<==>
preconditions();
String s;
if (mist() && shadow() && !(x instanceof String s))
throw q;
manyLinesOfStuff();
println(s); // s obscured by mist and shadow
Since the original s is always DU and never DA, we could choose
to allow the flow-bound s to merge with it. The binding would
then be discoverable as a dominating declaration, before the "if".
In this compromise, the dominating declaration would have to
be introduced before an entire if/else chain containing flow-scoped
bindings that are to be passed outside of the chain. That seems
reasonable to me, as a compromise between conciseness and
ease of reading.
— John
