Flow scoping

[Brian Goetz]

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 <amaembo at gmail.com 
> <mailto:amaembo at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190108/f95b2e58/attachment.html>