www.digitalmars.com         C & C++   DMDScript  

D - Maybe this has been done to death...

reply Kef Li <Kef_member pathlink.com> writes:
But there are two things in the specification that keep nagging at me. I for one
don't see any disadvantage to making fall-through explicit. Implicit
fall-through causes many bugs (heck, I've had them happen). The counter-argument
here seems to be that making it break implicitly would be too confusing or could
also lead to bugs by people who use C or C++ a lot, etc...but what's wrong with
making them BOTH explicit? If a new case label is reached without either (say)
fall; or break; it's an error. Maybe it's too late to add something like this,
but I just wonder why it's not done this way. I know you shouldn't baby
programmers, but you shouldn't invite them to shoot themselves in the foot,
either! You'd get the same capability, just safer.

Another thing I wonder about is why newlines are allowed in string
literals...what's wrong with the C way of doing it? Maybe this isn't so
important, but it's a similar issue: you don't really gain anything, but you
lose something (what if you want a one-line string literal and just forget the
closing quotation mark?).

So, can somebody please explain these to me? Or at least point me to posts where
these has been discussed? (We need an automatic search thing on this forum...)
I'm not "anti-D" by any means, it's just these things kind of bug me, like we're
still making the mistakes of other languages...

- Kef
Aug 17 2003
next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
"Kef Li" <Kef_member pathlink.com> wrote in message
news:bhobkk$7oi$1 digitaldaemon.com...

 If a new case label is reached without either (say)
 fall; or break; it's an error.

I like this idea but I dont like introducing any new keywords, maybe issue a warning 'case label with no break ' etc. Charles
Aug 17 2003
parent reply Kef Li <Kef_member pathlink.com> writes:
 If a new case label is reached without either (say)
 fall; or break; it's an error.

I like this idea but I dont like introducing any new keywords, maybe issue a warning 'case label with no break ' etc. Charles

I think introducing a new keyword would outweigh the hazards: I'd rather have more keywords than more bugs, so long as the language still provides the necessary degrees of freedom. Also, I believe the language and compiler are designed that no circumstance can produce a mere "warning", only an error. Warnings don't exist, because bad programmers (i.e., most people) would ignore them because they're "only" warnings. - Kef
Aug 17 2003
next sibling parent reply "Luna Kid" <lunakid neuropolis.org> writes:
 Another thing I wonder about is why newlines are allowed in string
 literals...what's wrong with the C way of doing it? Maybe this isn't so
 important, but it's a similar issue: you don't really gain anything, but you
 lose something (what if you want a one-line string literal and just forget the
 closing quotation mark?).

I *love* the D way, allowing copy-pasting multi-line text directly to the source without fiddling with those bloody quotes... Cheers, Sz.
Aug 17 2003
parent Kef Li <Kef_member pathlink.com> writes:
In article <bhpbo3$1md8$1 digitaldaemon.com>, Luna Kid says...
 Another thing I wonder about is why newlines are allowed in string
 literals...what's wrong with the C way of doing it? Maybe this isn't so
 important, but it's a similar issue: you don't really gain anything, but you
 lose something (what if you want a one-line string literal and just forget the
 closing quotation mark?).

I *love* the D way, allowing copy-pasting multi-line text directly to the source without fiddling with those bloody quotes... Cheers, Sz.

Hmm...perhaps there should be a way to distinguish a "normal" string literal and a "multi-line" string literal? I know that would be bordering on feature creep for the strings, but we all may forget the terminating quote to a string every now and then...so there should be a way to distinguish, perhaps by not changing the way normal string literals look, but maybe add a one-character prefix to them? Or how about this: make a capital-letter prefix mean a multi-line string and a small-letter prefix mean a normal string, but if you're not using a hex string or a WYSIWYG string, use a capital M for multi-line string and nothing for a normal string? Maybe make only WYSIWYG and hex strings multi-line? I'm not really passionate about this particular subject, I'm just interested in preventing bugs and confusing/misleading error messages. - Kef
Aug 18 2003
prev sibling parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
"Kef Li" <Kef_member pathlink.com> a ιcrit dans le message de
news:bhoelt$bo2$1 digitaldaemon.com...
 If a new case label is reached without either (say)
 fall; or break; it's an error.

I like this idea but I dont like introducing any new keywords, maybe


warning 'case label with no break ' etc.

Charles

I think introducing a new keyword would outweigh the hazards: I'd rather

 more keywords than more bugs, so long as the language still provides the
 necessary degrees of freedom. Also, I believe the language and compiler

 designed that no circumstance can produce a mere "warning", only an error.
 Warnings don't exist, because bad programmers (i.e., most people) would

 them because they're "only" warnings.

 - Kef

I don't think that any new keyword is necessary (or any warnings). Just require that all cases end with break (or return, goto,....). If someone want to fall through an explicit goto would be required. Maybe continue could mean to cotinue to the next statement but IMO this is not a good solution as inside a loop it would works differently than in C++. So the solution could be !break; or a goto to the next case label... And in my opinion, grouping cases should only works by grouping label (1, 2, 7..9 : some code) and not by stacking multiple labels: 1: 2: 7: 8: 9: some code IMO implicit fall-through is an error in C/C++ and we should correct it by supporting only explicit fall-through.
Aug 18 2003
parent reply Kef Li <Kef_member pathlink.com> writes:
I don't think that any new keyword is necessary (or any warnings). Just
require
that all cases end with break (or return, goto,....). If someone want to
fall through
an explicit goto would be required.

Maybe continue could mean to cotinue to the next statement but IMO this is
not a good solution as inside a loop it would works differently than in C++.

So the solution could be !break; or a goto to the next case label...

And in my opinion, grouping cases should only works by grouping label
(1, 2, 7..9 : some code) and not by stacking multiple labels:

1:
2:
7:
8:
9:
    some code

IMO implicit fall-through is an error in C/C++ and we should correct it
by supporting only explicit fall-through.

Using "continue" to move to the next statement would definitely be bad; it's counterintuitive and wouldn't allow you to use the normal semantics of "continue" in a case statement. An explicit goto instead of a "fall" keyword isn't satisfactory because goto requires a label...you couldn't really use the case label as a label in this sense (for instance, what if you're switching a string? Would you goto a string literal?), so you'd need to make a "goto-style" label under the case label, which feels redundant and silly. The "!break" idea seems interesting, though it looks a little awkward...using an operator on a keyword is pretty unusual for C-like languages. Maybe if we put our minds to it we can find a more ideal solution. I agree with the idea of somehow grouping case labels, though, which will probably eliminate most of the times explicit fall-through is used, but it doesn't allow, say, Duff's Device and other more esoteric ideas... Any more ideas? - Kef
Aug 18 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
Kef Li wrote:

"!break;" is hard to distinguish visually, and makes urge to correct it 
since it looks like a typing mistake. :)

How about "goto next;"? It looks too much like "continue" - which i 
don't find counterintuitive at all. Loops have both "break" and 
"continue" - why shouldn't case also have both? Multiple levels of 
possible break/continue contexts are a general problem. That's why we 
have labelled loops.

Grouping labels is visually good anyway, so i'd vote for it independant 
of other solutuions.

-eye
Aug 18 2003
parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
I would be satisfied with goto next also (in that case, next should probably
be a keyword
or at least it should be an error if next could be another named target).

"Ilya Minkov" <midiclub 8ung.at> a ιcrit dans le message de
news:bhrdhg$1m3m$1 digitaldaemon.com...
 Kef Li wrote:

 "!break;" is hard to distinguish visually, and makes urge to correct it
 since it looks like a typing mistake. :)

 How about "goto next;"? It looks too much like "continue" - which i
 don't find counterintuitive at all. Loops have both "break" and
 "continue" - why shouldn't case also have both? Multiple levels of
 possible break/continue contexts are a general problem. That's why we
 have labelled loops.

 Grouping labels is visually good anyway, so i'd vote for it independant
 of other solutuions.

 -eye

Aug 18 2003
parent reply "Vathix" <vathix dprogramming.com> writes:
How about continue case; a continue by itself would be for a surrounding
loop. I like switch the way it is but I don't see any harm in requiring an
action before the next case. Allowing multiple cases separated with commas
in a single case is nice too.

"Philippe Mori" <philippe_mori hotmail.com> wrote in message
news:bhrp86$27oh$1 digitaldaemon.com...
 I would be satisfied with goto next also (in that case, next should

 be a keyword
 or at least it should be an error if next could be another named target).

 "Ilya Minkov" <midiclub 8ung.at> a ιcrit dans le message de
 news:bhrdhg$1m3m$1 digitaldaemon.com...
 Kef Li wrote:

 "!break;" is hard to distinguish visually, and makes urge to correct it
 since it looks like a typing mistake. :)

 How about "goto next;"? It looks too much like "continue" - which i
 don't find counterintuitive at all. Loops have both "break" and
 "continue" - why shouldn't case also have both? Multiple levels of
 possible break/continue contexts are a general problem. That's why we
 have labelled loops.

 Grouping labels is visually good anyway, so i'd vote for it independant
 of other solutuions.

 -eye


Aug 18 2003
next sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
For me this would also be OK and clear.

The best would be a keyword nextcase (and also goto case(expr))

"Vathix" <vathix dprogramming.com> a ιcrit dans le message de
news:bhs8d5$2ssu$1 digitaldaemon.com...
 How about continue case; a continue by itself would be for a surrounding
 loop. I like switch the way it is but I don't see any harm in requiring an
 action before the next case. Allowing multiple cases separated with commas
 in a single case is nice too.

 "Philippe Mori" <philippe_mori hotmail.com> wrote in message
 news:bhrp86$27oh$1 digitaldaemon.com...
 I would be satisfied with goto next also (in that case, next should

 be a keyword
 or at least it should be an error if next could be another named


 "Ilya Minkov" <midiclub 8ung.at> a ιcrit dans le message de
 news:bhrdhg$1m3m$1 digitaldaemon.com...
 Kef Li wrote:

 "!break;" is hard to distinguish visually, and makes urge to correct



 since it looks like a typing mistake. :)

 How about "goto next;"? It looks too much like "continue" - which i
 don't find counterintuitive at all. Loops have both "break" and
 "continue" - why shouldn't case also have both? Multiple levels of
 possible break/continue contexts are a general problem. That's why we
 have labelled loops.

 Grouping labels is visually good anyway, so i'd vote for it



 of other solutuions.

 -eye



Aug 19 2003
prev sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
I like this also, it addes no new keywords and is the clearest so far.


switch (foo) {
    case BAR: continue case;
    case FOO:
        DoBar();
}

like that ?

Charles

"Vathix" <vathix dprogramming.com> wrote in message
news:bhs8d5$2ssu$1 digitaldaemon.com...
 How about continue case; a continue by itself would be for a surrounding
 loop. I like switch the way it is but I don't see any harm in requiring an
 action before the next case. Allowing multiple cases separated with commas
 in a single case is nice too.

 "Philippe Mori" <philippe_mori hotmail.com> wrote in message
 news:bhrp86$27oh$1 digitaldaemon.com...
 I would be satisfied with goto next also (in that case, next should

 be a keyword
 or at least it should be an error if next could be another named


 "Ilya Minkov" <midiclub 8ung.at> a ιcrit dans le message de
 news:bhrdhg$1m3m$1 digitaldaemon.com...
 Kef Li wrote:

 "!break;" is hard to distinguish visually, and makes urge to correct



 since it looks like a typing mistake. :)

 How about "goto next;"? It looks too much like "continue" - which i
 don't find counterintuitive at all. Loops have both "break" and
 "continue" - why shouldn't case also have both? Multiple levels of
 possible break/continue contexts are a general problem. That's why we
 have labelled loops.

 Grouping labels is visually good anyway, so i'd vote for it



 of other solutuions.

 -eye



Aug 19 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
I do

"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bhu57g$2qbj$1 digitaldaemon.com...
 I like this also, it addes no new keywords and is the clearest so far.


 switch (foo) {
     case BAR: continue case;
     case FOO:
         DoBar();
 }

 like that ?

 Charles

 "Vathix" <vathix dprogramming.com> wrote in message
 news:bhs8d5$2ssu$1 digitaldaemon.com...
 How about continue case; a continue by itself would be for a surrounding
 loop. I like switch the way it is but I don't see any harm in requiring


 action before the next case. Allowing multiple cases separated with


 in a single case is nice too.

 "Philippe Mori" <philippe_mori hotmail.com> wrote in message
 news:bhrp86$27oh$1 digitaldaemon.com...
 I would be satisfied with goto next also (in that case, next should

 be a keyword
 or at least it should be an error if next could be another named


 "Ilya Minkov" <midiclub 8ung.at> a ιcrit dans le message de
 news:bhrdhg$1m3m$1 digitaldaemon.com...
 Kef Li wrote:

 "!break;" is hard to distinguish visually, and makes urge to correct



 since it looks like a typing mistake. :)

 How about "goto next;"? It looks too much like "continue" - which i
 don't find counterintuitive at all. Loops have both "break" and
 "continue" - why shouldn't case also have both? Multiple levels of
 possible break/continue contexts are a general problem. That's why




 have labelled loops.

 Grouping labels is visually good anyway, so i'd vote for it



 of other solutuions.

 -eye




Aug 19 2003
prev sibling next sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bhu57g$2qbj$1 digitaldaemon.com>, Charles Sanders wrote:
 I like this also, it addes no new keywords and is the clearest so far.
 
 
 switch (foo) {
     case BAR: continue case;
     case FOO:
         DoBar();
 }
 
 like that ?

Sounds a bit contorted, like the dreaded "~Destructor()" and "virtual void f() = 0" syntax, both of which were invented to avoid new keywords. I'd really prefer just: switch (foo) { case BAR: continue; case FOO: DoBar(); } Even though the semantics of it is different of the usual C semantics, I don't think it is a big issue because the semantics of switch would be different in any case. Every old C warhorse that would learn about D's brand new glorious switch statement would think to himself along these lines: - So I don't need to say "break" in every leg of the case statement... Awmighty, that's just great! But hey, how the hell am I going to implement my precious Duff's device then? ... ah, I see that "continue" does what it actually should... no problem, let's keep that in mind. I'd guess I'd be better off using the named "break" statement anyway, 'cos the language offers such luxury! (An answer to the original poster: Yes, the issue has been beaten to death several times. Last time we tried to overthrow the "switch" throne was about a year ago, I think, and Walter strongly disagreed because of C/C++ compatibility. But you never know, maybe he's softened since ;) -Antti
Aug 19 2003
next sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 I like this also, it addes no new keywords and is the clearest so far.


 switch (foo) {
     case BAR: continue case;
     case FOO:
         DoBar();
 }

 like that ?

Sounds a bit contorted, like the dreaded "~Destructor()" and "virtual void f() = 0" syntax, both of which were invented to avoid new keywords. I'd really prefer just: switch (foo) { case BAR: continue; case FOO: DoBar(); } Even though the semantics of it is different of the usual C semantics, I don't think it is a big issue because the semantics of switch would be different in any case. Every old C warhorse that would learn about D's brand new glorious switch statement would think to himself along these lines:

I think we should avoid it as using switch inside a loop would mean that continue would not goes to the same place as C... but you may be right that we should do it that way anyway because C is already broken by having break that is affected by a switch but not continue. So for consistency, both break and continue should have local scope and require an identifier to affect a loop in an outside scope. We could also accept continue case for even safier coding (and make sure the code won't compile if cut&paste to a C program).
Aug 19 2003
prev sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Antti Sykδri" <jsykari gamma.hut.fi> wrote in message
news:slrnbk5dhd.4q6.jsykari pulu.hut.fi...
|
| (An answer to the original poster: Yes, the issue has been beaten to
| death several times. Last time we tried to overthrow the "switch" throne
| was about a year ago, I think, and Walter strongly disagreed because of
| C/C++ compatibility. But you never know, maybe he's softened since ;)
|
| -Antti
|

He can soften. Operator overloading has been in D for about a year now, and
before it was implemented, I remember Walter saying many things against it,
or how it wasn't needed. IIRC, same thing happened with templates. But then
numerous posts made him change his mind.
I, for one, don't like fall-thru switch statements, and many have said the
same. Maybe, if given the right reasons (something I won't do), he could
agree that C/C++ compatibility is not really important. Only time will tell
what he decides.

—————————————————————————
Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 2003-08-19
Aug 19 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
How about making neither the old or the new way explicit, but requiring each
case to end in one of:

 break
 return
 continue
 fallthrough

That way, no-one can mistakenly write in a mindset that is not correct,
because the compiler would disallow any implicit end-of-case action


"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:bhui14$9kl$1 digitaldaemon.com...
 "Antti Sykδri" <jsykari gamma.hut.fi> wrote in message
 news:slrnbk5dhd.4q6.jsykari pulu.hut.fi...
 |
 | (An answer to the original poster: Yes, the issue has been beaten to
 | death several times. Last time we tried to overthrow the "switch" throne
 | was about a year ago, I think, and Walter strongly disagreed because of
 | C/C++ compatibility. But you never know, maybe he's softened since ;)
 |
 | -Antti
 |

 He can soften. Operator overloading has been in D for about a year now,

 before it was implemented, I remember Walter saying many things against

 or how it wasn't needed. IIRC, same thing happened with templates. But

 numerous posts made him change his mind.
 I, for one, don't like fall-thru switch statements, and many have said the
 same. Maybe, if given the right reasons (something I won't do), he could
 agree that C/C++ compatibility is not really important. Only time will

 what he decides.

 -------------------------
 Carlos Santander


 ---
 Outgoing mail is certified Virus Free.
 Checked by AVG anti-virus system (http://www.grisoft.com).
 Version: 6.0.512 / Virus Database: 309 - Release Date: 2003-08-19

Aug 19 2003
parent "Philippe Mori" <philippe_mori hotmail.com> writes:
I agree that all path should be terminated explicitly.  In fact, continue,
continue next,
fallthrough, continue(expr) or whatever is used to fall-thought the next
case would be
required when nothing is used presently but we will still need to uses break
when we
do not want to break.

In fact, I think that we can already fall though the next case by using a
labelled
statement for that case and goto that case (as we can also do in C++) and we
will only need to require each case to be terminated explicitly.

switch (cond)
{
case 1:
    f1();
    goto label_a;    // I think we can already do that:

case 2:
label_a:
    f2();
    break;
}

And this solution has the advantage that it is compatible with C++
although not used very often... and it should very easy for the compiler
to detect implicit fall-through and generate an error...

"Matthew Wilson" <matthew stlsoft.org> a ιcrit dans le message de
news:bhuiit$aal$1 digitaldaemon.com...
 How about making neither the old or the new way explicit, but requiring

 case to end in one of:

  break
  return
  continue
  fallthrough

And also goto and throw...
 That way, no-one can mistakenly write in a mindset that is not correct,
 because the compiler would disallow any implicit end-of-case action


 "Carlos Santander B." <carlos8294 msn.com> wrote in message
 news:bhui14$9kl$1 digitaldaemon.com...
 "Antti Sykδri" <jsykari gamma.hut.fi> wrote in message
 news:slrnbk5dhd.4q6.jsykari pulu.hut.fi...
 |
 | (An answer to the original poster: Yes, the issue has been beaten to
 | death several times. Last time we tried to overthrow the "switch"


 | was about a year ago, I think, and Walter strongly disagreed because


 | C/C++ compatibility. But you never know, maybe he's softened since ;)
 |
 | -Antti
 |

 He can soften. Operator overloading has been in D for about a year now,

 before it was implemented, I remember Walter saying many things against

 or how it wasn't needed. IIRC, same thing happened with templates. But

 numerous posts made him change his mind.
 I, for one, don't like fall-thru switch statements, and many have said


 same. Maybe, if given the right reasons (something I won't do), he could
 agree that C/C++ compatibility is not really important. Only time will

 what he decides.

 -------------------------
 Carlos Santander


 ---
 Outgoing mail is certified Virus Free.
 Checked by AVG anti-virus system (http://www.grisoft.com).
 Version: 6.0.512 / Virus Database: 309 - Release Date: 2003-08-19


Aug 19 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
That's almost good, but I don't like it because it looks confusingly similar
to:

foo = FOO;
while(true)
{
    switch (foo) {
        case BAR: continue;
        case X:
        case FOO:
            DoBar();
    }
    break; // look I've written a new kind of   do{ DoBar(); } while
(foo==BAR);   statement!
}

There's cases all over inside a switch statement.  Adding another one will
only serve to confuse the eyes.  Can you think of another keyword?

Maybe we shouldn't use a keyword *statement* at all, perhaps it should be a
keyword *label*, indicating that it's a chain label that suppresses the
warning about the missing break for the prior case.

    switch (foo) {
        case BAR:
        //  This is a continue label.
        case continue:  // that's a COLON, not a semicolon!  The normal
continue statement is available for continuing loops.
        case FOO:
            DoBar();
    }

Maybe that is about the same as your idea, visually.  ;)

Obviously these are bad examples since ideally in this case you'd just say

    switch (foo) {
        case BAR,FOO: DoBar();
    }

Sean

"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bhu57g$2qbj$1 digitaldaemon.com...
 I like this also, it addes no new keywords and is the clearest so far.


 switch (foo) {
     case BAR: continue case;
     case FOO:
         DoBar();
 }

 like that ?

 Charles

Aug 20 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
     switch (foo) {
         case BAR,FOO: DoBar();
     }

Is that valid D? Cool!
Aug 20 2003
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Probably not.

I thought it was put in at some point, but upon looking at the D Programming
Language website, under Switch Statement, I don't see any mention of it.
;(

Sean


"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bhvco0$1f56$1 digitaldaemon.com...
     switch (foo) {
         case BAR,FOO: DoBar();
     }

Is that valid D? Cool!

Aug 20 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
Bummer

"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bhveht$1hn6$1 digitaldaemon.com...
 Probably not.

 I thought it was put in at some point, but upon looking at the D

 Language website, under Switch Statement, I don't see any mention of it.
 ;(

 Sean


 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bhvco0$1f56$1 digitaldaemon.com...
     switch (foo) {
         case BAR,FOO: DoBar();
     }

Is that valid D? Cool!


Aug 20 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bhvco0$1f56$1 digitaldaemon.com...
     switch (foo) {
         case BAR,FOO: DoBar();
     }

Is that valid D?

It isn't, but it probably should be.
Sep 30 2003
parent Lio <Lio_member pathlink.com> writes:
     switch (foo) {
         case BAR,FOO: DoBar();
     }



Ow, please, pretty please, allow ranges too, like in pascal (right?). Don't know about the syntax though, definately not "case 2-4:" but maybe "case 2..3:" ? (two dot's to not interfere with ... :-S ) Lio.
Oct 01 2003
prev sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bhvc4t$1ed5$1 digitaldaemon.com...
|
|     switch (foo) {
|         case BAR,FOO: DoBar();
|     }
|

For me, it's great.

—————————————————————————
Carlos Santander
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bhvc4t$1ed5$1 digitaldaemon.com...
|
|     switch (foo) {
|         case BAR,FOO: DoBar();
|     }
|

For me, it's great.

—————————————————————————
Carlos Santander
Aug 20 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Kef Li" <Kef_member pathlink.com> wrote in message
news:bhobkk$7oi$1 digitaldaemon.com...
 Another thing I wonder about is why newlines are allowed in string
 literals...what's wrong with the C way of doing it? Maybe this isn't so
 important, but it's a similar issue: you don't really gain anything, but

 lose something (what if you want a one-line string literal and just forget

 closing quotation mark?).

" The reason for that is so you can enclose an entire block of text, like this one, as one string literal. Otherwise, especially if it's a large block cut & pasted from elsewhere, it gets tedious adding all the \n and double quotes everywhere. "
Aug 18 2003
parent Alen Siljak <alen djesi.ba> writes:
Walter wrote:
 "
 The reason for that is so you can enclose an entire block of text,
 like this one, as one string literal. Otherwise, especially if it's a large
 block
 cut & pasted from elsewhere, it gets tedious adding all the \n and double
 quotes
 everywhere.
 "
 

I really like this. It is very useful when changing the enclosed SQL command. This way it's much easier to cut/paste SQL code into another tool to test/change it and then bring it back into program code. Metta, Alen
Aug 19 2003