digitalmars.D - Suggestion: new switch statement
- Kristian (39/39) Aug 21 2006 It would be nice if there was a new statement that acts like 'switch'
- Jeff (12/12) Aug 21 2006 How about allowing:
- Kristian (26/38) Aug 21 2006 Actually I also thought about that very syntax. :) However, I guess that...
- mike (41/78) Aug 21 2006 Hi!
-
Stewart Gordon
(22/45)
Aug 25 2006
- nobody (27/41) Aug 21 2006 The answer is that you can do interesting things in switch statements. P...
- Stewart Gordon (12/26) Aug 24 2006 Please see my proposal of the same thing from years ago:
- Kristian (8/24) Aug 24 2006 Grhm, that was over 2.5 years ago... :(
- Wim Vander Schelden (11/28) Aug 21 2006 I think the non-curly bracket version is nicer, as it shows how closely ...
- BCS (5/12) Aug 21 2006 no need for a unbreak, use:
- Chad J (28/77) Aug 21 2006 Creating a new type of switch statement just to change some default
- Rioshin an'Harthen (6/31) Aug 22 2006 Me, too.
- Kristian (70/137) Aug 22 2006 I too think that curly brackets in switch fits nively to the syntax of t...
It would be nice if there was a new statement that acts like 'switch'
except that 'break' will be automatically added at the end of the case
statements. (We don't want to change the behavior of 'switch' because
it'll break old code and confuse people familiar with C/C++.)
Let call this new statement 'jump' (or something), for example:
void func(int val) {
jump(val) {
case 1:
doX();
case 2, 3:
doY();
default:
doZ();
}
}
Using 'switch', 'func()' would look, of course, as follows:
void func(int val) {
switch(val) {
case 1:
doX();
break;
case 2, 3:
doY();
break;
default:
doZ();
break;
}
}
You could use a 'unbreak' (or something) to allow execution to fall
through to the next case statement.
In addition, falling through should be allowed in the following case:
case 1:
case 2:
which is a longer way to write "case 1, 2:", of course.
I think breaking after a case is (a lot) more common than falling through.
So this will reduce bugs (a programmer can easily forget to put the break
statement at the end of a case). Also, it'll make code shorter and easier
to read.
Aug 21 2006
How about allowing:
switch (val) {
case (1) {
doX();
} case (2, 3) {
doY();
} default {
doZ();
}
)
Or would this create some horrible syntactic ambiguities? Or, on the
other hand, it could just be too damn ugly. ;)
Aug 21 2006
On Mon, 21 Aug 2006 13:06:49 +0300, Jeff <psychobrat gmail.com> wrote:How about allowing: switch (val) { case (1) { doX(); } case (2, 3) { doY(); } default { doZ(); } ) Or would this create some horrible syntactic ambiguities? Or, on the =other hand, it could just be too damn ugly. ;)Actually I also thought about that very syntax. :) However, I guess that= = there are people out there that are not so fond of having more curly = brackets... In a way it'd fit the structure of the language, though. But, as you mentioned, it could confuse people and generate more bugs. = Also note that this is ok in D: void func(int val) { switch(val) { case 1: doX(); break; case 2: { int b =3D 2; //a local variable inside a block doY(b); } break; } } So, I think it would be better just use different statement. (And for a = = compiler, it'd be simple to implement.) Heheh, I just tested the switch statement, and guess what? I forgot to p= ut = the break statements at the end of cases...!!
Aug 21 2006
Hi!
If I may comment on that - I think that fits perfectly into the syntax. =
=
Think of that:
' class foo
' {
' // you can write public in 3 different ways
' public int x;
' public
' {
' int y;
' }
' public:
' int z;
' }
Why not something similar with switch?
' switch (i)
' {
' // you could write case in 3 different ways too
' case 1 writefln("case 1");
' case 2
' {
' writefln("case 2");
' }
' case 3:
' writefln("case 3");
' break;
' }
That would be really nice of one has lots of 1-line switch cases. I'd li=
ke =
that very much.
-Mike
Am 21.08.2006, 13:05 Uhr, schrieb Kristian <kjkilpi gmail.com>:
On Mon, 21 Aug 2006 13:06:49 +0300, Jeff <psychobrat gmail.com> wrote:=
How about allowing:
switch (val) {
case (1) {
doX();
} case (2, 3) {
doY();
} default {
doZ();
}
)
Or would this create some horrible syntactic ambiguities? Or, on the =
=
other hand, it could just be too damn ugly. ;)
Actually I also thought about that very syntax. :) However, I guess th=
at =
there are people out there that are not so fond of having more curly =
brackets... In a way it'd fit the structure of the language, though.
But, as you mentioned, it could confuse people and generate more bugs.=
=
Also note that this is ok in D:
void func(int val) {
switch(val) {
case 1:
doX();
break;
case 2:
{
int b =3D 2; //a local variable inside a block
doY(b);
}
break;
}
}
So, I think it would be better just use different statement. (And for =
a =
compiler, it'd be simple to implement.)
Heheh, I just tested the switch statement, and guess what? I forgot to=
=
put the break statements at the end of cases...!!
-- =
Erstellt mit Operas revolution=E4rem E-Mail-Modul: http://www.opera.com/=
mail/
Aug 21 2006
Stewart Gordon <smjg_1998 yahoo.com>
mike wrote:
Hi!
If I may comment on that - I think that fits perfectly into the syntax.
Think of that:
' class foo
' {
' // you can write public in 3 different ways
' public int x;
' public
' {
' int y;
' }
' public:
' int z;
' }
Why not something similar with switch?
' switch (i)
' {
' // you could write case in 3 different ways too
' case 1 writefln("case 1");
<snip>
Allowing {} to be omitted would create parsing ambiguities.
case qwert (yuiop) (asdfg());
Is this equivalent to
case qwert:
yuiop(asdfg());
break;
or
case qwert(yuiop):
asdfg();
break;
?
Stewart.
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------
My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.
Aug 25 2006
Jeff wrote:
How about allowing:
switch (val) {
case (1) {
doX();
} case (2, 3) {
doY();
} default {
doZ();
}
)
Or would this create some horrible syntactic ambiguities? Or, on the
other hand, it could just be too damn ugly. ;)
The answer is that you can do interesting things in switch statements. Probably
the most famous example is Duff's Device which you can see an example of in the
Mixin section of the D docs:
http://www.digitalmars.com/d/mixin.html
template duffs_device(alias id1, alias id2, alias s)
{
void duff_loop()
{
if (id1 < id2)
{
typeof(id1) n = (id2 - id1 + 7) / 8;
switch ((id2 - id1) % 8)
{
case 0: do { s();
case 7: s();
case 6: s();
case 5: s();
case 4: s();
case 3: s();
case 2: s();
case 1: s();
} while (--n > 0);
}
}
}
}
Aug 21 2006
Jeff wrote:
How about allowing:
switch (val) {
case (1) {
doX();
} case (2, 3) {
doY();
} default {
doZ();
}
)
Or would this create some horrible syntactic ambiguities? Or, on the
other hand, it could just be too damn ugly. ;)
Please see my proposal of the same thing from years ago:
http://www.digitalmars.com/d/archives/22722.html
Stewart.
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------
My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.
Aug 24 2006
On Thu, 24 Aug 2006 21:12:31 +0300, Stewart Gordon <smjg_1998 yahoo.com> wrote:Jeff wrote:Grhm, that was over 2.5 years ago... :( I know there are much important things to get right and working, but I sure do hope that Walter will someday (after 1.0?) improve the syntax for some parts. But yes, range definitions would be good to have indeed. It never occured to me that cases could have else statements, that could be nice also. :)How about allowing: switch (val) { case (1) { doX(); } case (2, 3) { doY(); } default { doZ(); } ) Or would this create some horrible syntactic ambiguities? Or, on the other hand, it could just be too damn ugly. ;)Please see my proposal of the same thing from years ago: http://www.digitalmars.com/d/archives/22722.html Stewart.
Aug 24 2006
On Mon, 21 Aug 2006 12:00:47 +0300, Kristian wrote:
It would be nice if there was a new statement that acts like 'switch'
except that 'break' will be automatically added at the end of the case
statements. (We don't want to change the behavior of 'switch' because
it'll break old code and confuse people familiar with C/C++.)
Let call this new statement 'jump' (or something), for example:
void func(int val) {
jump(val) {
case 1:
doX();
case 2, 3:
doY();
default:
doZ();
}
}
I think the non-curly bracket version is nicer, as it shows how closely it
is linked to the switch statement, and you don't have to put all those
useless symbols in. I find it very annoying to type curly brackets with
if/else/elseif statements, and I think many azerty-users do. We have to
press altgr-9 to get one, which is a long way for fingers to stretch.
Curly brackets or not, I think this jump thing would make a great addition
to the language, and I completely agree with you on the break thing:
falling through is something that I rarely use, and I've forgotten more
than enough break; statements for one lifetime.
-Wim
Aug 21 2006
Kristian wrote:It would be nice if there was a new statement that acts like 'switch' except that 'break' will be automatically added at the end of the case statements.[...]You could use a 'unbreak' (or something) to allow execution to fall through to the next case statement.no need for a unbreak, use: goto case; http://www.digitalmars.com/d/statement.html#goto
Aug 21 2006
Kristian wrote:
It would be nice if there was a new statement that acts like 'switch'
except that 'break' will be automatically added at the end of the case
statements. (We don't want to change the behavior of 'switch' because
it'll break old code and confuse people familiar with C/C++.)
Let call this new statement 'jump' (or something), for example:
void func(int val) {
jump(val) {
case 1:
doX();
case 2, 3:
doY();
default:
doZ();
}
}
Using 'switch', 'func()' would look, of course, as follows:
void func(int val) {
switch(val) {
case 1:
doX();
break;
case 2, 3:
doY();
break;
default:
doZ();
break;
}
}
You could use a 'unbreak' (or something) to allow execution to fall
through to the next case statement.
In addition, falling through should be allowed in the following case:
case 1:
case 2:
which is a longer way to write "case 1, 2:", of course.
I think breaking after a case is (a lot) more common than falling
through. So this will reduce bugs (a programmer can easily forget to
put the break statement at the end of a case). Also, it'll make code
shorter and easier to read.
Creating a new type of switch statement just to change some default
behavior seems a bit excessive.
At the same time, I can't stand the fall-through default behavior! It
is a source of bugs, and I've already been hit by it a few times in D
and spent hours trying to find the bug in a switch statement that
behaves subtly different than what I expected.
I've read that this is maintained in D to keep it easy to port C code
over to D. That's understandable, especially if you want to make break
the default, which would change the meaning of code without any warning.
I'd suggest though, that you don't allow a default ending for case
blocks at all. Mandate that each case block be followed by an escape
like 'break', 'return', 'goto', 'throw', etc. That way, the compiler
would throw an error when C code that uses fallthroughs is inadvertently
used as D code. Also, this is one of those things from C/C++ that is
bad. D is supposed to get rid of those bad things even if it means
losing backwards compatibility, so please get rid of this bad thing that
comes from C.
I also like Mike's suggestion on this thread a lot. It could even be
combined with my suggestion. I'd say use Mike's suggestion, and only
apply my suggestion to the colon blocks. Since the brackets and
one-liners are not valid C syntax AFAIK, the compiler won't need to
mandate anything about them to flush out bugs from incoming C code. On
the developer side, this trades nasty runtime bugs for some small amount
of hunting down compiler errors and fixing them. A good trade IMO. Not
sure what the cost would be to compiler writers like Walter, but please
at least implement the mandatory ending on the current case blocks, or
something just as good.
Aug 21 2006
"Chad J" <gamerChad _spamIsBad_gmail.com> wrote:At the same time, I can't stand the fall-through default behavior! It is a source of bugs, and I've already been hit by it a few times in D and spent hours trying to find the bug in a switch statement that behaves subtly different than what I expected. I've read that this is maintained in D to keep it easy to port C code over to D. That's understandable, especially if you want to make break the default, which would change the meaning of code without any warning. I'd suggest though, that you don't allow a default ending for case blocks at all. Mandate that each case block be followed by an escape like 'break', 'return', 'goto', 'throw', etc. That way, the compiler would throw an error when C code that uses fallthroughs is inadvertently used as D code. Also, this is one of those things from C/C++ that is bad. D is supposed to get rid of those bad things even if it means losing backwards compatibility, so please get rid of this bad thing that comes from C. I also like Mike's suggestion on this thread a lot. It could even be combined with my suggestion. I'd say use Mike's suggestion, and only apply my suggestion to the colon blocks. Since the brackets and one-liners are not valid C syntax AFAIK, the compiler won't need to mandate anything about them to flush out bugs from incoming C code. On the developer side, this trades nasty runtime bugs for some small amount of hunting down compiler errors and fixing them. A good trade IMO. Not sure what the cost would be to compiler writers like Walter, but please at least implement the mandatory ending on the current case blocks, or something just as good.Me, too. I hate forgetting to type a break statement at the end of a case. It's usually a pain in the *** to find. Enforcing the break, continue, etc. at the end of a case is a good way to remove unnecessary bugs. Thus, votes++
Aug 22 2006
I too think that curly brackets in switch fits nively to the syntax of the
language, as Mike here demostrated. And I also understand, as Chad said,
why a new switch statement is a bit too extreme.
Well now, currently there are four solutions:
1) A new switch statement (e.g. jump or branch).
2) The switch statement using different notation (curly brackets).
3) The compiler forces to use breaks etc at the end of cases.
4) A combination of the solutions 2 and 3.
Solution 1:
Pros:
- No breaking through bugs.
- Does not break old code.
- Does not require breaks etc at the end of cases.
- You'll instantly know that breaking always happen at the end of cases
(if not defined otherwise) when looking at code.
- Does not require brackets (some people don't like them).
- Allows doing complex case structures easily (usually a bad thing, but
sometimes necessary, maybe).
Cons:
- Two statements that do similar tasks yet differently. (Personally I
don't think this is a problem though.)
- Allows doing complex case structures easily (sometimes a good thing,
maybe).
Solution 2:
Pros:
- Does not break old code.
- Fits to the language syntax nicely.
- Only one statement doing switching/jumping/branching.
- Allows doing complex case structures easily (usually a bad thing, but
sometimes necessary, maybe).
Cons:
- You have to be a little more careful when using it. You may end up
allowing a break through when not wanted. Will people accustomed to old
switch syntax adapt to use the new one?
- Uses brackets (some people don't like them). (Personally I don't mind
using them.)
- Allows doing complex case structures easily (sometimes a good thing,
maybe).
Solution 3:
Pros:
- No breaking through bugs.
- Does not break old code as _itself_ (see the cons).
- You know instantly that breaking etc always happen at the end of cases
when looking at code.
- Complex case structures are somewhat harder to do (sometimes a bad
thing, maybe).
Cons:
- In old code, where breaking through is required, you have to modify the
code to keep it compiling. This can be considered as "breaking old code".
And changing old code may introduce new bugs.
- Takes more typing. If you forget a break statement, then you have to
edit the code and recompile.
- Complex case structures are somewhat harder to do (usually a good thing,
though).
The simplest and safest solution seems to be 1. The solution 2 is more
'beautiful' syntaxically (well, at least people who don't like curly
brackets may disagree with this). However, it's not so safe to use than
the solution 1, I think. Solution 3 is also safe. However, it requires
more typing and it may 'break' old code.
Maybe we could have both the solutions 1 and 2? (Or not...) ;)
I think solutions 3 and 2+3 are not accepted (by public) because of this
old code breaking issue... but maybe it's not an issue at all in practice.
Btw, it's quite funny/sad that (quite) many seem to hate curly brackets.
C/C++, D, etc, are so called curly brackets languages after all.
Well, I am not fond of them either, pressing AltGr + 7 and AltGr + 0 is
not so fast/easy as it should be (usually pressing AltGr + 7 requires two
hands). Fortunately my text editor's macro will add { and } to a statement
by pressing Ctrl + Enter. Usually it works fine, even.
On Tue, 22 Aug 2006 04:56:40 +0300, Chad J
<gamerChad _spamIsBad_gmail.com> wrote:
Kristian wrote:
It would be nice if there was a new statement that acts like 'switch'
except that 'break' will be automatically added at the end of the case
statements. (We don't want to change the behavior of 'switch' because
it'll break old code and confuse people familiar with C/C++.)
Let call this new statement 'jump' (or something), for example:
void func(int val) {
jump(val) {
case 1:
doX();
case 2, 3:
doY();
default:
doZ();
}
}
Using 'switch', 'func()' would look, of course, as follows:
void func(int val) {
switch(val) {
case 1:
doX();
break;
case 2, 3:
doY();
break;
default:
doZ();
break;
}
}
You could use a 'unbreak' (or something) to allow execution to fall
through to the next case statement.
In addition, falling through should be allowed in the following case:
case 1:
case 2:
which is a longer way to write "case 1, 2:", of course.
I think breaking after a case is (a lot) more common than falling
through. So this will reduce bugs (a programmer can easily forget to
put the break statement at the end of a case). Also, it'll make code
shorter and easier to read.
Creating a new type of switch statement just to change some default
behavior seems a bit excessive.
At the same time, I can't stand the fall-through default behavior! It
is a source of bugs, and I've already been hit by it a few times in D
and spent hours trying to find the bug in a switch statement that
behaves subtly different than what I expected.
I've read that this is maintained in D to keep it easy to port C code
over to D. That's understandable, especially if you want to make break
the default, which would change the meaning of code without any warning.
I'd suggest though, that you don't allow a default ending for case
blocks at all. Mandate that each case block be followed by an escape
like 'break', 'return', 'goto', 'throw', etc. That way, the compiler
would throw an error when C code that uses fallthroughs is inadvertently
used as D code. Also, this is one of those things from C/C++ that is
bad. D is supposed to get rid of those bad things even if it means
losing backwards compatibility, so please get rid of this bad thing that
comes from C.
I also like Mike's suggestion on this thread a lot. It could even be
combined with my suggestion. I'd say use Mike's suggestion, and only
apply my suggestion to the colon blocks. Since the brackets and
one-liners are not valid C syntax AFAIK, the compiler won't need to
mandate anything about them to flush out bugs from incoming C code. On
the developer side, this trades nasty runtime bugs for some small amount
of hunting down compiler errors and fixing them. A good trade IMO. Not
sure what the cost would be to compiler writers like Walter, but please
at least implement the mandatory ending on the current case blocks, or
something just as good.
Aug 22 2006
Hi!
Have you ever tried to use the thumb for alt-gr and pressing 7/0 with th=
e =
middle finger? Works well for me. I had an english keyboard some time, w=
as =
nice for coding, but writing emails or forum posts (in german) without =
umlauts was just irritating.
Anyway, I thought a bit about that.
I'd really like the switch to look like that:
' switch (bar)
' {
' case (1) writefln("case 1");
' case (2, 3)
' {
' writefln("case 1");
' writefln("or case 3");
' }
' case (4)
' {
' writefln("case 4 - need to fall through to 5");
' continue(5); // continue is used =
instead of falling through
' }
' case (5)
' {
' writefln("case 5 - checking for foo");
' if (!foo()) break; // breaks out of the =
switch
' writefln("foo is true");
' }
' default
' {
' writefln("default");
' throw new Exception("Don't do that!");
' }
' }
With the parenthesis and the continue. But if you try to mix that with t=
he =
current switch syntax, like
' switch (bar)
' {
' case (1) writefln("case 1");
' case 2: evil_flag =3D true; // fall through
' case (3) if (evil_flag) { ... }
' }
it's getting ugly. What about allowing my proposed syntax and aborting =
compilation when one tries to mix C-style switches with what I have in =
mind?
-Mike
Am 22.08.2006, 14:39 Uhr, schrieb Kristian <kjkilpi gmail.com>:
I too think that curly brackets in switch fits nively to the syntax of=
=
the language, as Mike here demostrated. And I also understand, as Chad=
=
said, why a new switch statement is a bit too extreme.
Well now, currently there are four solutions:
1) A new switch statement (e.g. jump or branch).
2) The switch statement using different notation (curly brackets).
3) The compiler forces to use breaks etc at the end of cases.
4) A combination of the solutions 2 and 3.
Solution 1:
Pros:
- No breaking through bugs.
- Does not break old code.
- Does not require breaks etc at the end of cases.
- You'll instantly know that breaking always happen at the end of case=
s =
(if not defined otherwise) when looking at code.
- Does not require brackets (some people don't like them).
- Allows doing complex case structures easily (usually a bad thing, bu=
t =
sometimes necessary, maybe).
Cons:
- Two statements that do similar tasks yet differently. (Personally I =
=
don't think this is a problem though.)
- Allows doing complex case structures easily (sometimes a good thing,=
=
maybe).
Solution 2:
Pros:
- Does not break old code.
- Fits to the language syntax nicely.
- Only one statement doing switching/jumping/branching.
- Allows doing complex case structures easily (usually a bad thing, bu=
t =
sometimes necessary, maybe).
Cons:
- You have to be a little more careful when using it. You may end up =
allowing a break through when not wanted. Will people accustomed to ol=
d =
switch syntax adapt to use the new one?
- Uses brackets (some people don't like them). (Personally I don't min=
d =
using them.)
- Allows doing complex case structures easily (sometimes a good thing,=
=
maybe).
Solution 3:
Pros:
- No breaking through bugs.
- Does not break old code as _itself_ (see the cons).
- You know instantly that breaking etc always happen at the end of cas=
es =
when looking at code.
- Complex case structures are somewhat harder to do (sometimes a bad =
thing, maybe).
Cons:
- In old code, where breaking through is required, you have to modify =
=
the code to keep it compiling. This can be considered as "breaking old=
=
code". And changing old code may introduce new bugs.
- Takes more typing. If you forget a break statement, then you have to=
=
edit the code and recompile.
- Complex case structures are somewhat harder to do (usually a good =
thing, though).
The simplest and safest solution seems to be 1. The solution 2 is more=
=
'beautiful' syntaxically (well, at least people who don't like curly =
brackets may disagree with this). However, it's not so safe to use tha=
n =
the solution 1, I think. Solution 3 is also safe. However, it requires=
=
more typing and it may 'break' old code.
Maybe we could have both the solutions 1 and 2? (Or not...) ;)
I think solutions 3 and 2+3 are not accepted (by public) because of th=
is =
old code breaking issue... but maybe it's not an issue at all in =
practice.
Btw, it's quite funny/sad that (quite) many seem to hate curly bracket=
s. =
C/C++, D, etc, are so called curly brackets languages after all.
Well, I am not fond of them either, pressing AltGr + 7 and AltGr + 0 i=
s =
not so fast/easy as it should be (usually pressing AltGr + 7 requires =
=
two hands). Fortunately my text editor's macro will add { and } to a =
statement by pressing Ctrl + Enter. Usually it works fine, even.
On Tue, 22 Aug 2006 04:56:40 +0300, Chad J =
<gamerChad _spamIsBad_gmail.com> wrote:
Kristian wrote:
It would be nice if there was a new statement that acts like 'switch=
' =
except that 'break' will be automatically added at the end of the =
case statements. (We don't want to change the behavior of 'switch' =
=
because it'll break old code and confuse people familiar with C/C++=
.)
Let call this new statement 'jump' (or something), for example:
void func(int val) {
jump(val) {
case 1:
doX();
case 2, 3:
doY();
default:
doZ();
}
}
Using 'switch', 'func()' would look, of course, as follows:
void func(int val) {
switch(val) {
case 1:
doX();
break;
case 2, 3:
doY();
break;
default:
doZ();
break;
}
}
You could use a 'unbreak' (or something) to allow execution to fall=
=
through to the next case statement.
In addition, falling through should be allowed in the following cas=
e:
case 1:
case 2:
which is a longer way to write "case 1, 2:", of course.
I think breaking after a case is (a lot) more common than falling =
=
through. So this will reduce bugs (a programmer can easily forget t=
o =
put the break statement at the end of a case). Also, it'll make cod=
e =
shorter and easier to read.
Creating a new type of switch statement just to change some default
behavior seems a bit excessive.
At the same time, I can't stand the fall-through default behavior! I=
t
is a source of bugs, and I've already been hit by it a few times in D=
and spent hours trying to find the bug in a switch statement that
behaves subtly different than what I expected.
I've read that this is maintained in D to keep it easy to port C code=
over to D. That's understandable, especially if you want to make bre=
ak
the default, which would change the meaning of code without any warni=
ng.
I'd suggest though, that you don't allow a default ending for case
blocks at all. Mandate that each case block be followed by an escape=
like 'break', 'return', 'goto', 'throw', etc. That way, the compiler=
would throw an error when C code that uses fallthroughs is inadverten=
tly
used as D code. Also, this is one of those things from C/C++ that is=
bad. D is supposed to get rid of those bad things even if it means
losing backwards compatibility, so please get rid of this bad thing t=
hat
comes from C.
I also like Mike's suggestion on this thread a lot. It could even be=
=
combined with my suggestion. I'd say use Mike's suggestion, and only=
=
apply my suggestion to the colon blocks. Since the brackets and =
one-liners are not valid C syntax AFAIK, the compiler won't need to =
mandate anything about them to flush out bugs from incoming C code. =
On =
the developer side, this trades nasty runtime bugs for some small =
amount of hunting down compiler errors and fixing them. A good trade=
=
IMO. Not sure what the cost would be to compiler writers like Walter=
, =
but please at least implement the mandatory ending on the current cas=
e =
blocks, or something just as good.
-- =
Erstellt mit Operas revolution=E4rem E-Mail-Modul: http://www.opera.com/=
mail/
Aug 22 2006
On Tue, 22 Aug 2006 18:55:29 +0300, mike <vertex gmx.at> wrote:Hi! Have you ever tried to use the thumb for alt-gr and pressing 7/0 with ==the middle finger?I do that also sometimes. Pressing AltGr+7 with the middle finger happen= s, = um, maybe 10-20% of the cases, at maximum, though. Pressing AltGr with a= = right hand's thumb and 7 with the left hand's middle finger does not = involve lifting my right elbow. Which seems to happen when using one han= d = only... Hey, that must be a reason why I have adopted the two hand = style... :)Anyway, I thought a bit about that. I'd really like the switch to look like that: ' switch (bar) ' { ' case (1) writefln("case 1"); ' case (2, 3) ' { ' writefln("case 1"); ' writefln("or case 3"); ' } ' case (4) ' { ' writefln("case 4 - need to fall through to 5"); ' continue(5); // continue is used =instead of falling through ' } ' case (5) ' { ' writefln("case 5 - checking for foo"); ' if (!foo()) break; // breaks out of the ==switch ' writefln("foo is true"); ' } ' default ' { ' writefln("default"); ' throw new Exception("Don't do that!"); ' } ' } With the parenthesis and the continue. But if you try to mix that with==the current switch syntax, like ' switch (bar) ' { ' case (1) writefln("case 1"); ' case 2: evil_flag =3D true; // fall through ' case (3) if (evil_flag) { ... } ' } it's getting ugly. What about allowing my proposed syntax and aborting==compilation when one tries to mix C-style switches with what I have in==mind? -MikeYeah, mixing the different syntaxes could make a mess. I guess compiler = = could produce error messages in such situations. Importantly it wouldn't= = break old code. Now this syntax will indeed fit to the overall syntax ("if() {}" <=3D> = "case() {}"). When I read my first book of C I wondered why the syntax o= f = the switch statement was different and not like this one. I guess that's= = because it will allow you to write some complex code. But this hybrid = style would allow that also.
Aug 23 2006
Am 23.08.2006, 15:09 Uhr, schrieb Kristian <kjkilpi gmail.com>:I do that also sometimes. Pressing AltGr+7 with the middle finger =happens, um, maybe 10-20% of the cases, at maximum, though. Pressing =AltGr with a right hand's thumb and 7 with the left hand's middle fing=er =does not involve lifting my right elbow. Which seems to happen when =using one hand only... Hey, that must be a reason why I have adopted t=he =two hand style... :)Hehe ... I never noticed that I actually do lift my right elbow every ti= me = I write curly braces. Now that's interesting :-) Writing code with a german keyboard layout is sometimes very interesting= . = Did you ever program in Turbo Pascal on DOS? Linked lists? My keyboard = driver was beeping every 10-20 seconds when I was programming (since you= = declare a pointer with the ^ character) :-)Yeah, mixing the different syntaxes could make a mess. I guess compile=r =could produce error messages in such situations. Importantly it wouldn='t =break old code. Now this syntax will indeed fit to the overall syntax ("if() {}" <=3D>=="case() {}"). When I read my first book of C I wondered why the syntax==of the switch statement was different and not like this one. I guess =that's because it will allow you to write some complex code. But this ==hybrid style would allow that also.To me that syntax looks and feels like D. It would also allow some prett= y = advanced control flow through the switch, like case (6) if (foo()) continue(7); else continue(8); Anyway: I'm kinda glad you brought this topic up, since I'm currently = toying aroung with designing a scripting language, and I hadn't yet = implemented a switch statement. Now that you've brought that up, I'll to= ss = the C-style switch out and implement it that way. Thanks! -Mike -- = Erstellt mit Operas revolution=E4rem E-Mail-Modul: http://www.opera.com/= mail/
Aug 23 2006