Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #39951 > unrolled thread

switch is shared declaration

Back to article view | Back to comp.lang.java.programmer

Contents

  switch is shared declaration "e.d.pro...@gmail.com" <e.d.programmer@gmail.com> - 2023-05-24 05:15 -0700
    Re: switch is shared declaration Arne Vajhøj <arne@vajhoej.dk> - 2023-05-24 12:57 -0400
      Re: switch is shared declaration Arne Vajhøj <arne@vajhoej.dk> - 2023-05-24 13:16 -0400
      Re: switch is shared declaration "e.d.pro...@gmail.com" <e.d.programmer@gmail.com> - 2023-05-24 11:05 -0700
        Re: switch is shared declaration Michael Jung <miju@golem.phantasia.org> - 2023-05-28 12:57 +0200
    Re: switch is shared declaration Marcel Mueller <news.5.maazl@spamgourmet.org> - 2023-05-28 13:31 +0200
      Re: switch is shared declaration Eric Sosman <esosman@comcast-dot-net.invalid> - 2023-05-28 08:36 -0400
        Re: switch is shared declaration Marcel Mueller <news.5.maazl@spamgourmet.org> - 2023-05-28 15:16 +0200
          Re: switch is shared declaration Arne Vajhøj <arne@vajhoej.dk> - 2023-05-28 13:42 -0400
        Re: switch is shared declaration Arne Vajhøj <arne@vajhoej.dk> - 2023-05-28 13:43 -0400

#39951 — switch is shared declaration

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

[toc] | [next] | [standalone]

#39952

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

[toc] | [prev] | [next] | [standalone]

#39953

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

[toc] | [prev] | [next] | [standalone]

#39954

> > 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.

[toc] | [prev] | [next] | [standalone]

#39955

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

[toc] | [prev] | [next] | [standalone]

#39956

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

[toc] | [prev] | [next] | [standalone]

#39957

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!

[toc] | [prev] | [next] | [standalone]

#39958

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

[toc] | [prev] | [next] | [standalone]

#39959

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

[toc] | [prev] | [next] | [standalone]

#39960

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web