Flow scoping

Remi Forax forax at univ-mlv.fr
Wed Jan 9 00:07:26 UTC 2019

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Tagir Valeev" <amaembo at gmail.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 8 Janvier 2019 23:55:19
> Objet: Re: Flow scoping

> On Jan 4, 2019, at 6:07 AM, Tagir Valeev < [ mailto:amaembo at gmail.com |
> 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".

Given that this feature will be used by beginners (writing equals is something you do early), i don't think it's a good idea. 

While the aim is perhaps noble, make the code more explicit, your proposal have the same kind of issues we had before 8 when the compiler was asking to declare the captured local variables final. 
- your proposal transform the problem from "why does it compile ?" to "why it don't compile ?". 
- if there is no declaration of 's', the error will be reported on 's' at the last line and most of the users will not know what to do. 
- the IDEs may help, but you should be able to write a basic Java program without an IDE (in jshell by example) and IDEs may declare 's' at the wrong place (the wrong scope) anyway. 
- Groovy, Kotlin have already this kind of feature and the branding "hey look the compiler is smart" seems enough. 
- i'm not even sure it makes the code more readable, at lot of users will not understand the code because it's like you can use 's' in the then branch ( 's' is declared above after all ). 

Basically, your proposal will just make the life of my students harder. 


> 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

More information about the amber-spec-observers mailing list