PM design question: Scopes

[Guy Steele]

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>