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




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


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


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


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


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




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


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


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


each

 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"




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


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


 Is that valid D?


It isn't, but it probably should be.


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


you

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


the

 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