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>
More information about the amber-spec-experts
mailing list