subj. the code:

  void main () {
    import std.stdio;
    char ch = '!';
    switch (ch) {
      int n = 42;
      case '!': writeln(n, ": wow!"); break;
      default:
    }
  }


i think that such abomination should:
1. be forbidden, or
2. trigger a warning, or
3. execute initializer anyway.

currently the code is allowed, no warnings triggered, yet `n` is uninitialized. and having uninitialized variable without "=void" "should not be".

On Wednesday, 29 April 2015 at 06:37:44 UTC, ketmar wrote:
> subj. the code:
>
>   void main () {
>     import std.stdio;
>     char ch = '!';
>     switch (ch) {
>       int n = 42;
>       case '!': writeln(n, ": wow!"); break;
>       default:
>     }
>   }
>
>
> i think that such abomination should:
> 1. be forbidden, or
> 2. trigger a warning, or
> 3. execute initializer anyway.
>
> currently the code is allowed, no warnings triggered, yet `n` is
> uninitialized. and having uninitialized variable without "=void" "should
> not be".

Agreed, this should be an error. Variables declared in one case block aren't even visible in other case blocks, this was probably an oversight.

On Wednesday, 29 April 2015 at 06:37:44 UTC, ketmar wrote:
> subj. the code:
>
>   void main () {
>     import std.stdio;
>     char ch = '!';
>     switch (ch) {
>       int n = 42;
>       case '!': writeln(n, ": wow!"); break;
>       default:
>     }
>   }
>
>
> i think that such abomination should:
> 1. be forbidden, or
> 2. trigger a warning, or
> 3. execute initializer anyway.
>
> currently the code is allowed, no warnings triggered, yet `n` is
> uninitialized. and having uninitialized variable without "=void" "should
> not be".

Please raise an issue in bugzilla. This is obviously an error.

On Wed, Apr 29, 2015 at 06:37:44AM +0000, ketmar via Digitalmars-d-learn wrote:
> subj. the code:
> 
>   void main () {
>     import std.stdio;
>     char ch = '!';
>     switch (ch) {
>       int n = 42;
>       case '!': writeln(n, ": wow!"); break;
>       default:
>     }
>   }
> 
> 
> i think that such abomination should:
> 1. be forbidden, or
> 2. trigger a warning, or
> 3. execute initializer anyway.
> 
> currently the code is allowed, no warnings triggered, yet `n` is uninitialized. and having uninitialized variable without "=void" "should not be".

Switch statements in D allow all sorts of abominations, if only you would try it. I think it was originally designed to support a particular loop idiom (sorry I forgot what it was called, and don't have time to look it up right now), but in the process this also opened the door to all sorts of nasty infelicities that probably breaks the type system, control flow, and many other things. Basically, the block inside a switch statement essentially amounts to free-for-all spaghetti code where you're free to jump around case labels willy-nilly, declare variables and jump over their initializations, break out of loops with goto case, or enter into the middle of a loop, and all sorts of other crazy things that, ostensibly, you shouldn't be able to do in a language like D.


T

-- 
Let's eat some disquits while we format the biskettes.

On 04/29/2015 07:57 AM, H. S. Teoh via Digitalmars-d-learn wrote:

> Switch statements in D allow all sorts of abominations, if only you
> would try it. I think it was originally designed to support a particular
> loop idiom (sorry I forgot what it was called

  http://en.wikipedia.org/wiki/Duff%27s_device

Ali

On 4/29/15 5:25 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> On Wednesday, 29 April 2015 at 06:37:44 UTC, ketmar wrote:
>> subj. the code:
>>
>>   void main () {
>>     import std.stdio;
>>     char ch = '!';
>>     switch (ch) {
>>       int n = 42;
>>       case '!': writeln(n, ": wow!"); break;
>>       default:
>>     }
>>   }
>>
>>
>> i think that such abomination should:
>> 1. be forbidden, or
>> 2. trigger a warning, or
>> 3. execute initializer anyway.
>>
>> currently the code is allowed, no warnings triggered, yet `n` is
>> uninitialized. and having uninitialized variable without "=void" "should
>> not be".
>
> Agreed, this should be an error. Variables declared in one case block
> aren't even visible in other case blocks, this was probably an oversight.

I thought they were? A switch scope is just like a normal scope, but with a bunch of labels.

They should be visible in all *trailing* case blocks, since the rule is that your code that uses it must come after the declaration.

I agree the above should not be allowed. It's clear the compiler can detect a situation where n is used but not initialized.

-Steve

On Wed, 29 Apr 2015 10:48:36 +0000, Gary Willoughby wrote:

> Please raise an issue in bugzilla. This is obviously an error.

done: https://issues.dlang.org/show_bug.cgi?id=14532

On Wed, 29 Apr 2015 07:57:07 -0700, H. S. Teoh via Digitalmars-d-learn wrote:

> Switch statements in D allow all sorts of abominations, if only you would try it. I think it was originally designed to support a particular loop idiom (sorry I forgot what it was called, and don't have time to look it up right now), but in the process this also opened the door to all sorts of nasty infelicities that probably breaks the type system, control flow, and many other things. Basically, the block inside a switch statement essentially amounts to free-for-all spaghetti code where you're free to jump around case labels willy-nilly, declare variables and jump over their initializations, break out of loops with goto case, or enter into the middle of a loop, and all sorts of other crazy things that, ostensibly, you shouldn't be able to do in a language like D.

yes, `switch` is one of those legacy cans of worms. i'm afraid that it's too late to redesign it, but it would be nice if each `case` will be an implicit `{}` block, and `goto case`/`break` will be allowed only as a last statement in `case` block. and unlabeled code in `switch` should be forbidden to.

but, as i said, it's too late to introduce such breaking change to language.