Flow scoping

Brian Goetz brian.goetz at oracle.com
Sun Dec 16 17:49:47 UTC 2018

> On Dec 16, 2018, at 12:32 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> at the same time, not introducing a variable in the scope avoid tricky use cases like
>  class A {
>    Object a;
>    void m(Object o) 
>      if (o instanceof A a) {
>        System.out.println(a);   // o at runtime
>      } else {
>        System.out.println(a);   // this.a at runtime
>      } 
>    }
>  }
> so in my opinion, neither 'not being in scope' nor 'not being DA' are good strategies because as you said below we want to be able to have name reuse in switch or if ... else.
> I think the best is to introduce the notion of poison variable, a variable that you can reuse but that is introduced in the scope, i.e. so your have the best of the two options.

Yes, we actually prototyped this, and we have some opinions about it.  But, the question of shadowing (which this is really about — what happens when a conditional variable with a non-contiguous scope shadows a field) seems secondary (if we do flow scoping, we can go either way with shadowing remediation, and if we don’t do flow scoping, it doesn’t matter.)  So I’m going to suggest that come back to this issue, and focus on the core scoping questions for a bit….

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20181216/007eb439/attachment-0001.html>

More information about the amber-spec-experts mailing list