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 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
the
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):
…
}
? Perhaps it is forbidden because the “int y” in the pattern would shadow the
“int y” in the ea
We had a long meeting regarding scoping and shadowing of pattern
variables. We ended up in a good place, and we were all a bit surprised
at where it seems to be pointing.
We started with two use cases that we thought were important:
Re-use of binding variables:
switch (x) {
cas
I’m late to this discussion because I’ve been traveling. But I do have a
comment about Scopes and pattern matching (see bottom).
> On Nov 3, 2017, at 6:44 AM, Gavin Bierman wrote:
>
> Scopes
>
> Java has five constructs that introduce fresh variables into scope: the local
> variable declara
> On Nov 4, 2017, at 4:46 PM, Mark Raynsford wrote:
>
> On 2017-11-03T10:44:51 +
> Gavin Bierman wrote:
>>
>> switch (o) {
>>case int i : ... // in scope and DA
>> ... // in scope and DA
>>case T i : // int i not in scope, so can re-use
>> }
>>
>
> I'm stro
On 2017-11-03T10:44:51 +
Gavin Bierman wrote:
>
> switch (o) {
> case int i : ... // in scope and DA
> ... // in scope and DA
> case T i : // int i not in scope, so can re-use
> }
> ... // i not in scope
> +ve Simple syntactic rule
> +ve Allows reuse of pattern
This mail is mostly about constraints; suggestions for addressing them
will come separately.
An existing roadblock on scopes is that the scope of a local declared in
a switch today is the entire switch, even though it is DU in most of the
switch:
switch (x) {
case 1:
Scopes
Java has five constructs that introduce fresh variables into scope: the local
variable declaration statement, the for statement, the try-with-resources
statement, the catch block, and lambda expressions. The first, local variable
declaration statements, introduce variables that are in sc
