> On Dec 16, 2018, at 12:32 PM, Remi Forax <fo...@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….
