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 <[email protected]> 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.
>
