I don't use a lot of switches so I hadn't realized this but:
this is invalid:
if (1==1) {
String s;
} else {
s = "1";
}

but this is fine:
switch (1) {
case -1:
String s;
break;
case 1:
s = "1";
break;
}

On 5/24/2023 8:15 AM, e.d.pro...@gmail.com wrote:
> I don't use a lot of switches so I hadn't realized this but:
> this is invalid:
> if (1==1) {
> String s;
> } else {
> s = "1";
> }
>
> but this is fine:
> switch (1) {
> case -1:
> String s;
> break;
> case 1:
> s = "1";
> break;
> }

The entire switch sort of has to be a single scope due to
fall through (no break) being valid.

Arne

On 5/24/2023 12:57 PM, Arne Vajhøj wrote:
> On 5/24/2023 8:15 AM, e.d.pro...@gmail.com wrote:
>> I don't use a lot of switches so I hadn't realized this but:
>> this is invalid:
>> if (1==1) {
>>    String s;
>> } else {
>>    s = "1";
>> }
>>
>> but this is fine:
>> switch (1) {
>> case -1:
>>    String s;
>>    break;
>> case 1:
>>    s = "1";
>>    break;
>> }
>
> The entire switch sort of has to be a single scope due to
> fall through (no break) being valid.

Difficult to come up with a good example where
the variable is always proper initialized.

But:

public class Fallthrough {
public static void main(String[] args) {
switch(3) {
case 3:
int z;
z = 1;
case 2:
z = 2;
case 1:
z = 3;
System.out.println(z);
}
}
}

Arne

> > I don't use a lot of switches so I hadn't realized this but:
> > this is invalid:
> > if (1==1) {
> > String s;
> > } else {
> > s = "1";
> > }
> >
> > but this is fine:
> > switch (1) {
> > case -1:
> > String s;
> > break;
> > case 1:
> > s = "1";
> > break;
> > }
> The entire switch sort of has to be a single scope due to
> fall through (no break) being valid.
>
> Arne

I guess it makes sense. You could call it a soft scope? In the if statement you get an undeclared variable error as it knows the if block will never execute with the else condition. In the switch statement it also will never execute both the declaration and the assignment, unless you remove the break. Since the break it optional, the compile sees it as one, though it also executes fine.

"e.d.pro...@gmail.com" <e.d.programmer@gmail.com> writes:
>> > I don't use a lot of switches so I hadn't realized this but:
>> > this is invalid:
>> > if (1==1) {
>> > String s;
>> > } else {
>> > s = "1";
>> > }
>> > but this is fine:
>> > switch (1) {
>> > case -1:
>> > String s;
>> > break;
>> > case 1:
>> > s = "1";
>> > break;
>> > }
>> The entire switch sort of has to be a single scope due to
>> fall through (no break) being valid.
>> Arne
> I guess it makes sense. You could call it a soft scope? In the if
> statement you get an undeclared variable error as it knows the if
> block will never execute with the else condition. In the switch
> statement it also will never execute both the declaration and the
> assignment, unless you remove the break. Since the break it optional,
> the compile sees it as one, though it also executes fine.

I wouldn't call it anything scope. Remember that you can create a lot of
mischief with labels and continue and breaks. And that needs to remain
compatible. And just because the compiler knows (can know) a block
cannot be reached, does not allow you to add illegal, but parseable
statements, e.g. "else { 0 = 1; }".

Am 24.05.23 um 14:15 schrieb e.d.pro...@gmail.com:
> but this is fine:
> switch (1) {
> case -1:
> String s;
> break;
> case 1:
> s = "1";
> break;
> }

Shouldn't this be a problem too because the 2nd switch label bypasses
the initialization of s?

Marcel

On 5/28/2023 7:31 AM, Marcel Mueller wrote:
> Am 24.05.23 um 14:15 schrieb e.d.pro...@gmail.com:
>> but this is fine:
>> switch (1) {
>> case -1:
>>    String s;
>>    break;
>> case 1:
>>    s = "1";
>>    break;
>> }
>
> Shouldn't this be a problem too because the 2nd switch label bypasses
> the initialization of s?

The `case 1:' part *is* the initialization of `s'. There is a
*declaration* of `s' in the `case -1:' part, but the declaration
does nothing (here) to initialize the `s' reference.

If we added another case to the switch, say

default:
System.out.println(s);
break;

.... the compiler would complain that `s' might be used without
being initialized, true. But the code as shown does not try
to retrieve any value from `s', so the compiler holds its peace.

There's really no mystery here at all. What e.d.programmer has
observed is simply that the block governed by `switch' is just
like any other block: A declaration within a block has scope
that runs from the declaration to the block end. The fact that
this block is part of a `switch' does not change matters: a
block is a block is a block.

--
esosman@comcast-dot-net.invalid
Look on my code, ye Hackers, and guffaw!

Am 28.05.23 um 14:36 schrieb Eric Sosman:
> On 5/28/2023 7:31 AM, Marcel Mueller wrote:
>> Shouldn't this be a problem too because the 2nd switch label bypasses
>> the initialization of s?
>
> The `case 1:' part *is* the initialization of `s'.  There is a
> *declaration* of `s' in the `case -1:' part, but the declaration
> does nothing (here) to initialize the `s' reference.
>
> If we added another case to the switch, say
>
>     default:
>         System.out.println(s);
>         break;
>
> ... the compiler would complain that `s' might be used without
> being initialized, true.   But the code as shown does not try
> to retrieve any value from `s', so the compiler holds its peace.

So ist is only valid because of the optimization?

String s;
is a default constructor call.

s = "1";
is an assignment operator call.
I expected the latter to be invalid without the first (unless String is
a trivial type).

> There's really no mystery here at all. What e.d.programmer has
> observed is simply that the block governed by `switch' is just
> like any other block: A declaration within a block has scope
> that runs from the declaration to the block end.

I know. Switch labels are nothing else than goto targets.

Marcel

On 5/28/2023 9:16 AM, Marcel Mueller wrote:
> Am 28.05.23 um 14:36 schrieb Eric Sosman:
>> On 5/28/2023 7:31 AM, Marcel Mueller wrote:
>>> Shouldn't this be a problem too because the 2nd switch label bypasses
>>> the initialization of s?
>>
>> The `case 1:' part *is* the initialization of `s'.  There is a
>> *declaration* of `s' in the `case -1:' part, but the declaration
>> does nothing (here) to initialize the `s' reference.
>>
>> If we added another case to the switch, say
>>
>>      default:
>>          System.out.println(s);
>>          break;
>>
>> ... the compiler would complain that `s' might be used without
>> being initialized, true.   But the code as shown does not try
>> to retrieve any value from `s', so the compiler holds its peace.
>
> So ist is only valid because of the optimization?

Not a traditional optimization.

The check if things used are guaranteed to be initialized
just do not apply.

>   String s;
> is a default constructor call.

No. s is just a reference not pointing to any object.

>   s = "1";
> is an assignment operator call.

An assignment.

> I expected the latter to be invalid without the first (unless String is
> a trivial type).

You can not assign to a variable not declared no matter whether
it is simple or not. But I suspect that was not what you meant.

String s;
s = "1";

is sort of equivalent to C:

char *s;
s = "1";

Arne

On 5/28/2023 8:36 AM, Eric Sosman wrote:
>> Am 24.05.23 um 14:15 schrieb e.d.pro...@gmail.com:
>>> but this is fine:
>>> switch (1) {
>>> case -1:
>>>    String s;
>>>    break;
>>> case 1:
>>>    s = "1";
>>>    break;
>>> }

> There's really no mystery here at all. What e.d.programmer has
> observed is simply that the block governed by `switch' is just
> like any other block: A declaration within a block has scope
> that runs from the declaration to the block end.  The fact that
> this block is part of a `switch' does not change matters: a
> block is a block is a block.

and case ... break; is not a block.

:-)

Arne