# PM design question: Scopes

Guy Steele guy.steele at oracle.com
Mon Nov 20 19:02:31 UTC 2017

```Okay, thanks for this clarification.  I am not a big fan of fall-through, and I think we could live with this example being an error.

(If it were to work as a natural consequence of whatever theory we finally adopt, I predict that it would get used in exactly this sort of defaulting situation.  On the other hand, it is not a completely general solution to the defaulting problem; consider

switch (x) {
case Quux(int y):
int x = y;
// would also like to get to the point after case Bar, but can’t “fall through” into it.
case Foo(int x):
int y = x;
// fall through
case Bar(int x, int y):
…
}

so perhaps it is just as well that we not encourage it.)

> On Nov 20, 2017, at 1:55 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>
> On 11/20/2017 1:33 PM, Guy Steele wrote:
>> I like this.  One question: what does this new theory have to say about the situation
>>
>> switch (x) {
>>   case Foo(int x):
>> 	int y = x;
>> 	// fall through
>>   case Bar(int x, int y):
>> 	…
>> }
>
> In this case, I would say that the second y is shadowing the first, and therefore this is an error.  Trying to merge the ys seems like a heroic measure.  Merging the xs, on the other hand, is clean, because at the point where the second x is bound, the first x is DU (we'd skip over the Bar(int x, int y) binding if we had matched the first case.)
>
> The opposite example is also interesting:
>
>     case Foo(int x, int y):
>         // A
>         // fall through
>     case Bar(int x):
>         // B
>
> Here, y is in scope in A, but not in B; x is in scope in both A and B.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20171120/fc64008b/attachment.html>
```