Jump to page: 1 2 3
Thread overview
switch statement
Aug 28, 2001
James Gilbert
Aug 28, 2001
John Waggenspack
Aug 28, 2001
Richard Krehbiel
Aug 28, 2001
James Gilbert
Aug 28, 2001
Russ Lewis
Aug 28, 2001
Chris Friesen
Aug 29, 2001
Russ Lewis
Aug 29, 2001
Dan Hursh
Aug 29, 2001
Chris Friesen
Aug 30, 2001
Dan Hursh
Re: switch statement - diagnose defualt:
Aug 30, 2001
Richard Krehbiel
Sep 03, 2001
James Gilbert
Aug 31, 2001
Russ Lewis
Aug 31, 2001
Ben Cohen
Aug 31, 2001
Russ Lewis
Sep 03, 2001
James Gilbert
Sep 04, 2001
Russ Lewis
Sep 04, 2001
Charles Jenkins
Sep 04, 2001
Charles Jenkins
Sep 05, 2001
Dan Hursh
Nov 04, 2001
Sean L. Palmer
Nov 05, 2001
Russ Lewis
Aug 31, 2001
Ben Cohen
Aug 30, 2001
Ben Cohen
August 28, 2001
Hi,

I really like the sound of "D".  I quite like Java,
but it takes for ever to compile and run, and C++
is just a mess.  If only there was a language with
a nice clean OO syntax, which would compile and run
as fast as C.  Hey, it sounds like "D" is it!

Reading through the spec, I am very happy to see
so many C language annoyances fixed.  But how about
fixing the switch statement?  I don't think
fall-through should be the default behaviour - surely
the default should be a break.  I'd advocate
something like:

    switch (i)
    {
        case 1:
            x = 3;
            fallthrough;
        case 2:
            x = 4;
        case 3:
            x = 5;
    }

Instead of:

    switch (i)
    {
        case 1:
            x = 3;
        case 2:
            x = 4;
            break;
        case 3:
            x = 5;
            break;
    }

Less typing, and the default action is the
most common one.  (Idea from "Expert C
Programming" by Peter van der Linden, page
34 onwards.  Great book!)

Just my $0.02,  James
August 28, 2001
Sounds good but my most common use of fallthrough is this:

switch (i)
{
    case 1:
    case 2:
        x = i;
        break;
    case 3:
    case 4:
        x = i + 1;
        break;
}

I would like the above to be a special case of fallthrough that didn't require the fallthrough keyword.

jwag

"James Gilbert" <jgrg@sanger.ac.uk> wrote in message news:3B8B80D0.48C7F694@sanger.ac.uk...
> Reading through the spec, I am very happy to see
> so many C language annoyances fixed.  But how about
> fixing the switch statement?  I don't think
> fall-through should be the default behaviour - surely
> the default should be a break.  I'd advocate
> something like:
>
>     switch (i)
>     {
>         case 1:
>             x = 3;
>             fallthrough;
>         case 2:
>             x = 4;
>         case 3:
>             x = 5;
>     }



August 28, 2001
"John Waggenspack" <jwag@ieee.org> wrote in message news:9mgdcr$1cej$1@digitaldaemon.com...
> Sounds good but my most common use of fallthrough is this:
>
> switch (i)
> {
>     case 1:
>     case 2:
>         x = i;
>         break;
>     case 3:
>     case 4:
>         x = i + 1;
>         break;
> }
>
> I would like the above to be a special case of fallthrough that didn't require the fallthrough keyword.

I think this could be accomodated simply enough with a small syntactic change:

switch(i)
{
    case 1, 2:
        // ...
    case 3, 4:

And, I'm not too crazy about the keyword "fallthrough".  Why not "continue?" It's already a reserved word.  And, we don't have to worry about legacy code with a legit "continue" within a switch.

Oh - I'd suggest continuing to use "break" to mean "exit from switch" in this context.

Have we addressed labelled "break" and "continue" statements yet?  Like this:

switch name (i)
{
    // complex nested algorithms...
        break name;
}

Allow the same syntax with "for", "while", and "do", of course.

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@home.com (personal)


August 28, 2001
Richard Krehbiel wrote:
> 
> "John Waggenspack" <jwag@ieee.org> wrote in message news:9mgdcr$1cej$1@digitaldaemon.com...
> > Sounds good but my most common use of fallthrough is this:
> >
> > switch (i)
> > {
> >     case 1:
> >     case 2:
> >         x = i;
> >         break;
> >     case 3:
> >     case 4:
> >         x = i + 1;
> >         break;
> > }
> >
> > I would like the above to be a special case of fallthrough that didn't require the fallthrough keyword.
> 
> I think this could be accomodated simply enough with a small syntactic change:
> 
> switch(i)
> {
>     case 1, 2:
>         // ...
>     case 3, 4:

Yes, this seems neat.

> And, I'm not too crazy about the keyword "fallthrough".  Why not "continue?" It's already a reserved word.  And, we don't have to worry about legacy code with a legit "continue" within a switch.

I don't care about the keyword.  As you have
to explicity fall through.

> Oh - I'd suggest continuing to use "break" to mean "exit from switch" in this context.
> 
> Have we addressed labelled "break" and "continue" statements yet?  Like this:
> 
> switch name (i)
> {
>     // complex nested algorithms...
>         break name;
> }
> 
> Allow the same syntax with "for", "while", and "do", of course.

Yes, these are "already implemented" for "for"
and "while".

-- 
James G.R. Gilbert
The Sanger Centre
Wellcome Trust Genome Campus
Hinxton
Cambridge                        Tel: 01223 494906
CB10 1SA                         Fax: 01223 494919
August 28, 2001
Richard Krehbiel wrote:

> I think this could be accomodated simply enough with a small syntactic change:
>
> switch(i)
> {
>     case 1, 2:
>         // ...
>     case 3, 4:

If we're going to do this, we should also allow ranges:

switch(c)
{
    case 'a'...'z','A'...'z':
     // ....
}

> And, I'm not too crazy about the keyword "fallthrough".  Why not "continue?" It's already a reserved word.  And, we don't have to worry about legacy code with a legit "continue" within a switch.

I thought about suggesting just this...but I don't really think it's a good idea.  continue already has a meaning that is something like "jump to next iteration of the loop".  I think that it would, in the long run, be confusing to overload its meaning as "fall through."  Kind of like static was overloaded ad nauseum...

What about using goto?  Could the 'case x' be seen as a label?

switch(c)
{
    case '0'...'9':
       foo();
       goto case 'a'...'z','A'...'Z';

    case 'a'...'z','A'...'Z';
       bar();
       goto default;

    default:
        baz();
};

While I don't like retyping those complex case ranges (copy-paste isn't too bad), it does have the upside of making it *very* easy to read and understand where you're going to.

August 28, 2001
Russ Lewis wrote:

> If we're going to do this, we should also allow ranges:
> 
> switch(c)
> {
>     case 'a'...'z','A'...'z':
>      // ....
> }

Amen!  I suggested this a while back.


> What about using goto?  Could the 'case x' be seen as a label?
> 
> switch(c)
> {
>     case '0'...'9':
>        foo();
>        goto case 'a'...'z','A'...'Z';
> 
>     case 'a'...'z','A'...'Z';
>        bar();
>        goto default;
> 
>     default:
>         baz();
> };


ick.

I REALLY don't want to have to type that much, even with cut and paste.
A 'fallthrough' keyword is completely satisfactory to me, and is very obvious as
to what it does.



-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com
August 29, 2001
Russ Lewis wrote:
> 
> Richard Krehbiel wrote:
> 
> > I think this could be accomodated simply enough with a small syntactic change:
> >
> > switch(i)
> > {
> >     case 1, 2:
> >         // ...
> >     case 3, 4:
> 
> If we're going to do this, we should also allow ranges:
> 
> switch(c)
> {
>     case 'a'...'z','A'...'z':
>      // ....
> }

	Well, I should let more knowledgeable people answer this, but they are
probably getting tired.  If my understanding of switch is correct, he is
a pretty thin abstraction of what the compiler is actually doing in
assembler (much like every flow control structure in C).  It was a
technique used in assembler for choosing between code locations to jump
to.

For your example above, the C syntax would be like:
	switch(c){
		case 'a': case 'b': case 'c': case 'd':
		case 'e': case 'f': case 'g': case 'h':
		.
		.
		.
	}

To the eye this is ugly.  Nobody would write this because it is
absolutely evil code.  Coincidentally, from what I understand (and I
could be wrong) but the generated code that matches is equally ugly.
Either the compiler writer would have to have some special optimize that
would translate this into something faster (like in if type structure)
or let the compiler spite out nasty code for something that looks
simple.
	I think the plan for D is to try to keep the syntax like C unless we
are correcting a side effect issue.  This will help people adjust to the
language and int this case it will probably keep the compiler simpler
(another goal so that it is easy to implement a complete and correct D
compiler).  Switch's fallthrough is not a side effect.  It's just not a
popular feature in modern high level languages.  Also, there a mess of
C/C++ and I believe Java programmers (Java has this syntax right?) who
already use this syntax.  Changing the behavior of switch would be like
changing the behavior of typedef.  (err... wait a moment...?)
	Also, in the example above, you have a range of characters.  Number are
fine semantically, but with character you have an added problem.  For
instance, if you support the systems native character set, and that
system is one of the crusty mainframes, you might be in for a surprise.
I believe some character sets do not have all the letters of the
alphabet ordered contiguously.  You might get some punctuation in that.
Does the compile assume ascii, unicode, the locale favorite, etc.?

> > And, I'm not too crazy about the keyword "fallthrough".  Why not "continue?" It's already a reserved word.  And, we don't have to worry about legacy code with a legit "continue" within a switch.
> 
> I thought about suggesting just this...but I don't really think it's a good idea.  continue already has a meaning that is something like "jump to next iteration of the loop".  I think that it would, in the long run, be confusing to overload its meaning as "fall through."  Kind of like static was overloaded ad nauseum...
> 
> What about using goto?  Could the 'case x' be seen as a label?
> 
> switch(c)
> {
>     case '0'...'9':
>        foo();
>        goto case 'a'...'z','A'...'Z';
> 
>     case 'a'...'z','A'...'Z';
>        bar();
>        goto default;
> 
>     default:
>         baz();
> };
> 
> While I don't like retyping those complex case ranges (copy-paste isn't too bad), it does have the upside of making it *very* easy to read and understand where you're going to.

	Given my argument above, I find arguing this moot.  Oh heck, I like to
argue.  Goto is ugly.  There I've said it.  It has it's uses but it
shouldn't have that many.

	How about this?  We add some way to allow the programmer to say he
wants break to be the default, in which case he would use continue
(because it's breaks counterpart in loops, not because I'm biased toward
continue or against the horribly ugly goto syntax requiring a label
name).
	We could maybe put a flag of some sort after the switch condition and
before the opening brace.  That would allow masochists like you to
declare you want pain and let the rest of use normal people continue
living oblivious to your lifestyle choices. :-)

Dan
August 29, 2001
Dan Hursh wrote:

> For your example above, the C syntax would be like:
>         switch(c){
>                 case 'a': case 'b': case 'c': case 'd':
>                 case 'e': case 'f': case 'g': case 'h':
>                 .
>                 .
>                 .
>         }
> 
> To the eye this is ugly.  Nobody would write this because it is absolutely evil code.  Coincidentally, from what I understand (and I could be wrong) but the generated code that matches is equally ugly. Either the compiler writer would have to have some special optimize that would translate this into something faster (like in if type structure) or let the compiler spite out nasty code for something that looks simple.

Any optimizing compiler already knows how to convert switches to if statements if it thinks it would speed things up.  Converting ranges is just another thing to check, and it makes the code a lot easier to read.  There are other languages that currently support ranges in switch/case statements.

I think that you're working too hard to keep D like C.  I would say that the vast majority of the time (even in C) the desired behaviour is to break.  If this is true, then lets make it the default behaviour, and it can then be overridden by a 'fallthrough' statement.

Anything that a) makes it easier to read, b) makes it easier to program, c)
means less typing, d) makes sense, and e) is relatively simple to implement
should, in my books, be included regardless of whether it is like C/C++.


-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com
August 29, 2001
Chris Friesen wrote:

> Russ Lewis wrote:
>
> > If we're going to do this, we should also allow ranges:
> >
> > switch(c)
> > {
> >     case 'a'...'z','A'...'z':
> >      // ....
> > }
>
> Amen!  I suggested this a while back.
>
> > What about using goto?  Could the 'case x' be seen as a label?
> >
> > switch(c)
> > {
> >     case '0'...'9':
> >        foo();
> >        goto case 'a'...'z','A'...'Z';
> >
> >     case 'a'...'z','A'...'Z';
> >        bar();
> >        goto default;
> >
> >     default:
> >         baz();
> > };
>
> ick.
>
> I REALLY don't want to have to type that much, even with cut and paste.
> A 'fallthrough' keyword is completely satisfactory to me, and is very obvious as
> to what it does.

Just occurred to me that it could be simpler; in the goto mention *any* valid value to jump to the case that would handle that value:

switch(c)
{
   case '0'...'9':
       foo();
       goto case 'a';

    case 'a'...'z','A'...'Z';
       bar();
       goto default;

    default:
        baz();
};

That reduces the typing A LOT.

And yes, I know (and firmly believe in) Goto Considered Harmful...I just wonder if 'goto' isn't more readable than 'continue' and doesn't require a new keyword like 'fallthrough'.

August 30, 2001
Chris Friesen wrote:

> 
> I think that you're working too hard to keep D like C.

Nothing worth doing is ever easy.  :-)

> I would say that the
> vast majority of the time (even in C) the desired behaviour is to break.  If
> this is true, then lets make it the default behaviour, and it can then be
> overridden by a 'fallthrough' statement.

I would still rather continue or the goto (where you only have to give
one case and not the whole range).

> Anything that a) makes it easier to read, b) makes it easier to program, c)
> means less typing, d) makes sense, and e) is relatively simple to implement
> should, in my books, be included regardless of whether it is like C/C++.

Would it be good to at least add the need for braces around a case?  The case labels look like goto label, and it looks like it is going to fall through.  Maybe that's my C background,  but labels don't look like block delimiters to me.

	switch(c){
		case 'a': case 'b': {

		}
		case 'c': case 'd': {

		}
	}

I just had an idea.


	switch (c){
		case 'a': case 'b':{
			// code for 'a' & 'b'
		}
		case 'c': case 'e':{
			// code for 'c' & 'e'
			case 'f':{
				// cade for 'f', 'c' & 'e'
			}
			// more code for 'c' & 'e'
		}
		default:{
			// code for anything but 'a', 'b', 'c', 'e' & 'f'
		}
	}

Thoughts?  Good?  Bad?  Ugly?  Plagiarized?

Dan
« First   ‹ Prev
1 2 3