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;
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"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; }".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)