On Tue, 22 Jun 2010 09:17:57 -0400, Adam Ruppe
wrote:
>
> What you guys are saying makes enough sense. switch will always be a
> series of labels and jumps in my mind, but I can deal with this.
>
> One note that I think is the main reason people find fallthrough
> confusing: they hit tab once t
On 06/22/2010 08:39 AM, Don wrote:
I think you misunderstood. I was arguing that there is no association
between 'goto' and loops. People who use goto, use it for error
handling, not for looping. I was by no means advocating the use of goto
for error handling!
Oh good :) The looping part wasn'
What you guys are saying makes enough sense. switch will always be a
series of labels and jumps in my mind, but I can deal with this.
One note that I think is the main reason people find fallthrough
confusing: they hit tab once too many times.
switch(a) {
case 10:
case 20: // obvious fall
Steven Schveighoffer, el 22 de junio a las 07:26 me escribiste:
> On Mon, 21 Jun 2010 20:40:14 -0400, Adam Ruppe
> wrote:
>
> >What's the point of a switch without implicit fallthrough?
>
> Maintenance. Using if statements instead of switch, you have to
> repeat the value to test for each of th
Lars T. Kyllingstad, el 22 de junio a las 09:14 me escribiste:
> On Mon, 21 Jun 2010 20:27:32 -0700, Bill Baxter wrote:
>
> > On Mon, Jun 21, 2010 at 6:31 PM, Leandro Lucarella
> > wrote:
> >> Bill Baxter, el 21 de junio a las 17:13 me escribiste:
> >>> On Mon, Jun 21, 2010 at 4:24 PM, Leandro Lu
Jeff Nowakowski wrote:
On 06/22/2010 12:06 AM, Don wrote:
Finally, goto is ugly and continue is strongly associated with looping.
? It's most commonly used in error handling.
But, fallthrough actually is a goto.
Do I really have to argue that goto is mostly deprecated, and has been
for deca
Steven Schveighoffer wrote:
On Mon, 21 Jun 2010 20:40:14 -0400, Adam Ruppe
wrote:
What's the point of a switch without implicit fallthrough?
Maintenance. Using if statements instead of switch, you have to repeat
the value to test for each of the cases. If you want to change the
value be
On Tue, 22 Jun 2010 02:40:14 +0200, Adam Ruppe
wrote:
What's the point of a switch without implicit fallthrough? If you take
that away, it offers nothing that if/elseif doesn't. (Aside from not
retyping the switch(stuff here), which you can bring into a function
anyway, so whoop-de-doo. And I
On 06/22/2010 12:06 AM, Don wrote:
Finally, goto is ugly and continue is strongly associated with looping.
? It's most commonly used in error handling.
But, fallthrough actually is a goto.
Do I really have to argue that goto is mostly deprecated, and has been
for decades? Lots of programming
On Mon, 21 Jun 2010 20:40:14 -0400, Adam Ruppe
wrote:
What's the point of a switch without implicit fallthrough?
Maintenance. Using if statements instead of switch, you have to repeat
the value to test for each of the cases. If you want to change the value
being tested, it's one chang
On Mon, 21 Jun 2010 20:27:32 -0700, Bill Baxter wrote:
> On Mon, Jun 21, 2010 at 6:31 PM, Leandro Lucarella
> wrote:
>> Bill Baxter, el 21 de junio a las 17:13 me escribiste:
>>> On Mon, Jun 21, 2010 at 4:24 PM, Leandro Lucarella
>>> wrote:
>>> > goto next case; is a little more verbose but very
Adam Ruppe wrote:
On 6/21/10, Andrei Alexandrescu wrote:
Then why are people using switch and next to nobody uses fall through
(provably including Walter, who thinks is using fall through "all the
time")?
Do you have some stats from the phobos and dmd source? I ran a crude
text pattern progra
On 6/22/10, Don wrote:
> Did you consider situations where the last thing before the case is
> actually a 'goto' ? Walter does that a lot.
Yeah, me too. I counted them the same as break (and continue, return,
and throw).
Here's my source. I know it has some false negatives and some false
positiv
BCS wrote:
> Hello Jonathan,
>
>> "goto case" does seem a bit silly, but I think that it's clearer and
>> less error prone for anyone who understands "goto case."
>
> Say I have some code with a fall through. If I use the goto case X;
> version, it allows the cases to be freely reordered. OTOH i
Jeff Nowakowski wrote:
On 06/21/2010 05:11 PM, Jonathan M Davis wrote:
Having something like "fallthrough" or "goto next case" would of
course be even clearer, but those would require new keywords.
I think "fallthrough" would be a perfect keyword to add here. C
programmers will immediately r
On 6/21/10, Andrei Alexandrescu wrote:
> Then why are people using switch and next to nobody uses fall through
> (provably including Walter, who thinks is using fall through "all the
> time")?
Do you have some stats from the phobos and dmd source? I ran a crude
text pattern program, and it said a
On Mon, Jun 21, 2010 at 6:31 PM, Leandro Lucarella wrote:
> Bill Baxter, el 21 de junio a las 17:13 me escribiste:
>> On Mon, Jun 21, 2010 at 4:24 PM, Leandro Lucarella
>> wrote:
>> > goto next case; is a little more verbose but very clear to me :)
>> >
>> > Maybe just next case; is a shorter al
Hello Jonathan,
"goto case" does seem a bit silly, but I think that it's clearer and
less error prone for anyone who understands "goto case."
Say I have some code with a fall through. If I use the goto case X; version,
it allows the cases to be freely reordered. OTOH if I use the other option
Bill Baxter, el 21 de junio a las 17:13 me escribiste:
> On Mon, Jun 21, 2010 at 4:24 PM, Leandro Lucarella wrote:
> > goto next case; is a little more verbose but very clear to me :)
> >
> > Maybe just next case; is a shorter alternative...
>
> That would be great if "next" were a D keyword. Bu
Jonathan M Davis, el 21 de junio a las 17:03 me escribiste:
> bearophile wrote:
>
> > Andrei Alexandrescu:
> >> The problem is, if Walter sees us bickering too much, he'll use that as
> >> pretext to veto out any improvement.
> >
> > You are wrong, Walter is an adult able to understand discussion
Adam Ruppe, el 21 de junio a las 20:40 me escribiste:
> What's the point of a switch without implicit fallthrough? If you take
> that away, it offers nothing that if/elseif doesn't. (Aside from not
> retyping the switch(stuff here), which you can bring into a function
> anyway, so whoop-de-doo. And
On 06/21/2010 07:40 PM, Adam Ruppe wrote:
What's the point of a switch without implicit fallthrough? If you take
that away, it offers nothing that if/elseif doesn't. (Aside from not
retyping the switch(stuff here), which you can bring into a function
anyway, so whoop-de-doo. And I guess some perf
What's the point of a switch without implicit fallthrough? If you take
that away, it offers nothing that if/elseif doesn't. (Aside from not
retyping the switch(stuff here), which you can bring into a function
anyway, so whoop-de-doo. And I guess some performance boosts in
rearranging the cases, but
On Mon, Jun 21, 2010 at 4:24 PM, Leandro Lucarella wrote:
> goto next case; is a little more verbose but very clear to me :)
>
> Maybe just next case; is a shorter alternative...
That would be great if "next" were a D keyword. But I don't think
you're going to get Walter to add a keyword just fo
Andrei Alexandrescu, el 21 de junio a las 15:31 me escribiste:
> On 06/21/2010 03:08 PM, Don wrote:
> >Andrei Alexandrescu wrote:
> >>On 06/19/2010 06:58 AM, Don wrote:
> >>>Andrei Alexandrescu wrote:
> Don wrote:
> [snip]
> >Or is too late to break backwards compatibility with B ?
> >>
Andrei Alexandrescu, el 21 de junio a las 15:25 me escribiste:
> On 06/21/2010 01:27 PM, Sean Kelly wrote:
> >Jonathan M Davis Wrote:
> >>
> >>In any case, that means that it could be made required to have a control
> >>statement at the end of a case block without having to specify a specific
> >>d
On 06/21/2010 06:56 PM, Jonathan M Davis wrote:
Andrei Alexandrescu wrote:
[snip]
Andrei
Well, "goto case" and "goto case XXX" both already exist. Both get the job
done. So, regardless of which would be better for fallthrough, we can choose
to use whichever we want in our code. As it stands
bearophile wrote:
> Andrei Alexandrescu:
>> The problem is, if Walter sees us bickering too much, he'll use that as
>> pretext to veto out any improvement.
>
> You are wrong, Walter is an adult able to understand discussions, not a
> capricious dictator :-) Syntax and other things require discuss
Did anyone suggest "continue case" instead of "continue switch"? That
sounds less ambiguous to me.
--bb
On Mon, Jun 21, 2010 at 4:56 PM, Jonathan M Davis wrote:
> Andrei Alexandrescu wrote:
>
> [snip]
>>
>>
>> Andrei
>
> Well, "goto case" and "goto case XXX" both already exist. Both get the job
Andrei Alexandrescu:
> The problem is, if Walter sees us bickering too much, he'll use that as
> pretext to veto out any improvement.
You are wrong, Walter is an adult able to understand discussions, not a
capricious dictator :-)
Syntax and other things require discussions, sometimes even longis
Andrei Alexandrescu wrote:
[snip]
>
>
> Andrei
Well, "goto case" and "goto case XXX" both already exist. Both get the job
done. So, regardless of which would be better for fallthrough, we can choose
to use whichever we want in our code. As it stands, it becomes a matter of
preference. I'd lo
On 06/21/2010 05:11 PM, Jonathan M Davis wrote:
Having something like "fallthrough" or "goto next case" would of
course be even clearer, but those would require new keywords.
I think "fallthrough" would be a perfect keyword to add here. C
programmers will immediately recognize it. Switch/case
On 06/21/2010 06:01 PM, Jonathan M Davis wrote:
Andrei Alexandrescu wrote:
After Sean's example, goto case XXX is my fave for fallthrough. I don't
like unlabeled "goto case" to mean fall through, it's one of those "need
to look in the manual" features. goto case XXX is generalized fall
through.
Andrei Alexandrescu wrote:
>
> After Sean's example, goto case XXX is my fave for fallthrough. I don't
> like unlabeled "goto case" to mean fall through, it's one of those "need
> to look in the manual" features. goto case XXX is generalized fall
> through.
>
> Andrei
Well, it definitely works,
On 06/21/2010 04:15 PM, Don wrote:
Jonathan M Davis wrote:
Sean Kelly wrote:
Jonathan M Davis Wrote:
In any case, that means that it could be made required to have a
control
statement at the end of a case block without having to specify a
specific
destination for fallthrough - though I'd pref
Jonathan M Davis Wrote:
> Sean Kelly wrote:
> >
> > It's a small thing, but I think "continue switch" could be misleading.
> > Consider this:
> >
> > switch (getState()) {
> > case X:
> > setState(Z);
> > continue switch;
> > case Y:
> > break;
> > case Z:
> > writeln( "done!" )
Andrei Alexandrescu Wrote:
> On 06/21/2010 01:27 PM, Sean Kelly wrote:
> > Jonathan M Davis Wrote:
> >>
> >> In any case, that means that it could be made required to have a control
> >> statement at the end of a case block without having to specify a specific
> >> destination for fallthrough - th
Don wrote:
>
> But 'goto case XXX' is an extremely rarely encountered construct, that
> screams 'Examine this code closely'. So I don't think it needs extra
> error checking.
Oh, I don't think that it's a big issue. We have "goto case XXX" and "goto
case," so we could use them to enforce flow co
Jonathan M Davis wrote:
Sean Kelly wrote:
Jonathan M Davis Wrote:
In any case, that means that it could be made required to have a control
statement at the end of a case block without having to specify a specific
destination for fallthrough - though I'd prefer "continue switch" over
"goto case
On 06/21/2010 03:46 PM, Sean Kelly wrote:
Andrei Alexandrescu wrote:
On 06/21/2010 01:27 PM, Sean Kelly wrote:
Jonathan M Davis Wrote:
In any case, that means that it could be made required to have a
control
statement at the end of a case block without having to specify a
specific
destinatio
Sean Kelly wrote:
> Jonathan M Davis Wrote:
>>
>> In any case, that means that it could be made required to have a control
>> statement at the end of a case block without having to specify a specific
>> destination for fallthrough - though I'd prefer "continue switch" over
>> "goto case" since it
On 06/21/2010 03:46 PM, Sean Kelly wrote:
Andrei Alexandrescu wrote:
On 06/21/2010 01:27 PM, Sean Kelly wrote:
Jonathan M Davis Wrote:
In any case, that means that it could be made required to have a
control
statement at the end of a case block without having to specify a
specific
destinatio
Andrei Alexandrescu wrote:
> On 06/21/2010 01:27 PM, Sean Kelly wrote:
>> Jonathan M Davis Wrote:
>>>
>>> In any case, that means that it could be made required to have a
> > > control
>>> statement at the end of a case block without having to specify a
> > > specific
>>> destination for fallthro
Don:
> I patched my DMD. Quite successful. It caught 8 bugs in Phobos, in code
> written by at least 4 different people. I think everyone gets stung by
> that B.
Thank you Don.
Bye,
bearophile
On 06/21/2010 03:08 PM, Don wrote:
Andrei Alexandrescu wrote:
On 06/19/2010 06:58 AM, Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
[snip]
Or is too late to break backwards compatibility with B ?
We can and should do it. It won't impact TDPL adversely.
Excellent! I'll make a patch for
On 06/21/2010 01:27 PM, Sean Kelly wrote:
Jonathan M Davis Wrote:
In any case, that means that it could be made required to have a control
statement at the end of a case block without having to specify a specific
destination for fallthrough - though I'd prefer "continue switch" over "goto
case"
Andrei Alexandrescu wrote:
On 06/19/2010 06:58 AM, Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
[snip]
Or is too late to break backwards compatibility with B ?
We can and should do it. It won't impact TDPL adversely.
Excellent! I'll make a patch for it when I have time.
Walter just g
Sean Kelly:
> Having never encountered D before, what would be your interpretation of this
> code?
Unfortunately the "continue case;" syntax looks about equally unintuitive to me
:-(
Bye,
bearophile
Jonathan M Davis Wrote:
>
> In any case, that means that it could be made required to have a control
> statement at the end of a case block without having to specify a specific
> destination for fallthrough - though I'd prefer "continue switch" over "goto
> case" since it's more explicit and le
KennyTM~:
> That is just C#'s switch syntax.
Some of the C# designers are people with a long experience in implementing
(Pascal-like) programming languages. Convergent evolution is a way to confirm
my idea was good, then :-)
>And I don't see how the current switch syntax is "hairy".<
Even if
KennyTM~ wrote:
> On Jun 19, 10 07:17, Jonathan M Davis wrote:
>> bearophile wrote:
>>
>>> 2) switch cases that don't end with goto or break:
>>>
>>> void main() {
>>> int x, y;
>>> switch (x) {
>>> case 0: y++;
>>> default: y--;
>>> }
>>> }
>>
>> I, for one, _want
On Jun 21, 10 17:52, bearophile wrote:
Andrei:
The intent is to only require a control flow transfer if there is at least one
statement after the label.<
The current switch syntax is already very hairy (even lot of people on this
newsgroup are ignorant about some parts of it!) and it contai
bearophile wrote:
Andrei:
The intent is to only require a control flow transfer if there is at least one
statement after the label.<
The current switch syntax is already very hairy (even lot of people on this
newsgroup are ignorant about some parts of it!) and it contains one or more
speci
Andrei:
>The intent is to only require a control flow transfer if there is at least one
>statement after the label.<
The current switch syntax is already very hairy (even lot of people on this
newsgroup are ignorant about some parts of it!) and it contains one or more
special cases. So I sugge
Hello Andrei,
On 06/20/2010 09:00 PM, bearophile wrote:
Michel Fortin:
But what about the "case 1: ... case 10:" syntax?
switch (x) {
case 1: .. case 10:
case 22: .. case 32:
case 52, 64:
doSomething();
break;
default:
whatever();
break;
}
Sorry, in my first answer I have a bit partially m
On 06/20/2010 09:00 PM, bearophile wrote:
Michel Fortin:
But what about the "case 1: ... case 10:" syntax?
switch (x) {
case 1: .. case 10:
case 22: .. case 32:
case 52, 64:
doSomething();
br
Michel Fortin:
> But what about the "case 1: ... case 10:" syntax?
>
> switch (x) {
> case 1: .. case 10:
> case 22: .. case 32:
> case 52, 64:
> doSomething();
> break;
> default:
>
Michel Fortin:
> But what about the "case 1: ... case 10:" syntax?
You are right, I think we have to make an exception on this then, and consider
that range a single entity.
(You have just found an example why a conceptually messed up syntax (like that
ranged one) always comes to bite us in the
On 2010-06-20 19:42:49 -0400, bearophile said:
I think he means every case. Sometimes a small change, even if seems a
little less handy, is useful. Can't you write code like this, that also
looks better to me?
import std.stdio: writeln;
void doSomething() { writeln("doSomething"); }
void wha
Sean Kelly:
> As long as there's a way to enumerate case labels I don't really care what
> the syntax is. That would be more than fine with me.
Good (note that the code I have written is already correct D syntax) :-)
Bye,
bearophile
bearophile Wrote:
> Sean Kelly:
> > You mean every label that is followed by a statement, correct? This is a
> > common idiom that I wouldn't want to change:
> >
> > switch (x) {
> > case 1: case 2: case 3: case 4:
> > doSomething();
> > break;
> > default:
> > whatever();
> > }
>
Sean Kelly:
> You mean every label that is followed by a statement, correct? This is a
> common idiom that I wouldn't want to change:
>
> switch (x) {
> case 1: case 2: case 3: case 4:
> doSomething();
> break;
> default:
> whatever();
> }
I think he means every case. Sometimes a sm
Andrei Alexandrescu Wrote:
> On 06/19/2010 06:58 AM, Don wrote:
> > Andrei Alexandrescu wrote:
> >> Don wrote:
> >> [snip]
> >>> Or is too late to break backwards compatibility with B ?
> >>
> >> We can and should do it. It won't impact TDPL adversely.
> >
> > Excellent! I'll make a patch for it w
Andrei Alexandrescu:
> He also agreed to give more thought to the restriction of forcing every
> swich label to be ended with a control flow transfer statement.
I hope Walter will express his positive vote about this other little C syntax
detail, automatic joining of adjacent strings:
http://d.p
Andrei Alexandrescu:
> Walter just gave the green light, so Don - it's up to you.
Probably our awesome Don will be able to do it, sooner or later :-)
> He also agreed to give more thought to the restriction of forcing every
> swich label to be ended with a control flow transfer statement.
Good
On 06/19/2010 06:58 AM, Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
[snip]
Or is too late to break backwards compatibility with B ?
We can and should do it. It won't impact TDPL adversely.
Excellent! I'll make a patch for it when I have time.
Walter just gave the green light, so Don
On Jun 19, 10 17:56, bearophile wrote:
KennyTM~:
This "fallthrough" statement already exists.
switch (x) {
case 0:
do_something();
goto case;
case 1:
do_more_thing();
goto case;
case 2:
done();
br
Andrei Alexandrescu, el 19 de junio a las 03:15 me escribiste:
> On 06/18/2010 10:08 PM, Vladimir Panteleev wrote:
> >On Sat, 19 Jun 2010 05:22:47 +0300, Andrei Alexandrescu
> > wrote:
> >
> >>Walter had no retort to that argument, so he veered into a critique of
> >>the goto case XXX solution sayi
Justin Johansson, el 19 de junio a las 23:24 me escribiste:
> Andrei Alexandrescu wrote:
> >On 06/19/2010 06:58 AM, Don wrote:
> >>Andrei Alexandrescu wrote:
> >>>Don wrote:
> >>>[snip]
> Or is too late to break backwards compatibility with B ?
> >>>
> >>>We can and should do it. It won't impac
That's funny, just yesterday I was reading about lazy evaluation in D from this
page:
http://www.digitalmars.com/d/2.0/lazy-evaluation.html
And then I noticed we could make our own switch-like structures.
(The code below the string "More complex user defined control structures")
Purists will,
Andrei Alexandrescu wrote:
On 06/19/2010 06:58 AM, Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
[snip]
Or is too late to break backwards compatibility with B ?
We can and should do it. It won't impact TDPL adversely.
Excellent! I'll make a patch for it when I have time.
You may want
On 06/19/2010 06:58 AM, Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
[snip]
Or is too late to break backwards compatibility with B ?
We can and should do it. It won't impact TDPL adversely.
Excellent! I'll make a patch for it when I have time.
You may want to make sure Walter approves
Andrei Alexandrescu wrote:
Don wrote:
[snip]
Or is too late to break backwards compatibility with B ?
We can and should do it. It won't impact TDPL adversely.
Excellent! I'll make a patch for it when I have time.
A perhaps little known thing is that D doesn't allow this:
int a, b, c;
if
KennyTM~:
> This "fallthrough" statement already exists.
>
> switch (x) {
> case 0:
> do_something();
> goto case;
> case 1:
> do_more_thing();
> goto case;
> case 2:
> done();
> break;
> default:
>
On 06/18/2010 10:08 PM, Vladimir Panteleev wrote:
On Sat, 19 Jun 2010 05:22:47 +0300, Andrei Alexandrescu
wrote:
Walter had no retort to that argument, so he veered into a critique of
the goto case XXX solution saying it's unmaintainable: when you moving
code around you want to keep on falling
On Jun 19, 10 07:17, Jonathan M Davis wrote:
bearophile wrote:
2) switch cases that don't end with goto or break:
void main() {
int x, y;
switch (x) {
case 0: y++;
default: y--;
}
}
I, for one, _want_ case statements to be able to fall through. It would be
ho
On Fri, 18 Jun 2010 20:17:09 -0700, Jonathan M Davis
wrote:
> >> I, for one, _want_ case statements to be able to fall through. It would
> >> be horribly painful in many cases if they couldn't. Now, requiring a
> >> separate statement like fallthrough or somesuch instead of break might
> >> not b
Vladimir Panteleev wrote:
> Well, if "goto case XXX" is unmaintainable, how about some combination of
> existing keywords? For example, "continue switch;".
Ooh. I like that. I don't know how well that would work with the grammar,
but it's fairly aesthetically pleasing and definitely more mainta
Andrei Alexandrescu wrote:
> Jonathan M Davis wrote:
>> bearophile wrote:
>>
>>> 2) switch cases that don't end with goto or break:
>>>
>>> void main() {
>>> int x, y;
>>> switch (x) {
>>> case 0: y++;
>>> default: y--;
>>> }
>>> }
>>
>> I, for one, _want_ case statem
bearophile wrote:
> Jonathan M Davis:
>
>>Well, I would pount out that you mentioning it more or less reopens the
>>discussion,<
>
> You are right, but probably Walter will not sue me for reopening an old
> thread ;-)
>
>
> In the things you are saying you seem to ignore the "goto" I have writ
On Sat, 19 Jun 2010 05:22:47 +0300, Andrei Alexandrescu
wrote:
Walter had no retort to that argument, so he veered into a critique of
the goto case XXX solution saying it's unmaintainable: when you moving
code around you want to keep on falling through but with goto you'd need
to update
On Fri, 18 Jun 2010 20:23:45 -0400, Jonathan M Davis
wrote:
bearophile wrote:
Jonathan M Davis:
but requiring that each case end with a break would seriously restrict
the usefulness of switch statements.
Time ago there was a long thread about this topic (and in the meantime
Walter has ad
On Fri, 18 Jun 2010 17:03:24 -0400, Don wrote:
In the comments for bug 4077, "Bugs caused by bitwise operator
precedence"
it was asked why C gave & with lower precedence than ==, when it is
unintuitive and a frequent source of bugs.
I was quite shocked to find that the reason is backwards
Jonathan M Davis wrote:
bearophile wrote:
2) switch cases that don't end with goto or break:
void main() {
int x, y;
switch (x) {
case 0: y++;
default: y--;
}
}
I, for one, _want_ case statements to be able to fall through. It would be
horribly painful in many ca
> As this (this is D syntax that you can already use):
>
> void main() {
> int x, y;
> switch (x) {
> case 0: y++; goto case 1;
> case 1: y++;
> default:
> }
> }
Sorry, I meant something like:
void main() {
int x, y;
switch (x) {
case 0: y++; g
Jonathan M Davis:
>Well, I would pount out that you mentioning it more or less reopens the
>discussion,<
You are right, but probably Walter will not sue me for reopening an old thread
;-)
In the things you are saying you seem to ignore the "goto" I have written two
times in my answers :-)
Jonathan M Davis wrote:
...
> the simplest answer would be if you have
> multiple values for the variable that your switching on which should all
> be using the same kind.
...
Yikes, that should be "using the same _code_."
bearophile wrote:
> Jonathan M Davis:
>> but requiring that each case end with a break would seriously restrict
>> the usefulness of switch statements.
>
> Time ago there was a long thread about this topic (and in the meantime
> Walter has added the "static switch" that burns the fat chance to ad
Jonathan M Davis:
> but requiring that each case end with a break would seriously restrict
> the usefulness of switch statements.
Time ago there was a long thread about this topic (and in the meantime Walter
has added the "static switch" that burns the fat chance to add to D2 a second
safer swi
bearophile wrote:
> 2) switch cases that don't end with goto or break:
>
> void main() {
> int x, y;
> switch (x) {
> case 0: y++;
> default: y--;
> }
> }
I, for one, _want_ case statements to be able to fall through. It would be
horribly painful in many cases if the
bearophile:
> >>> 1 < 5 < 10
> True
It's especially useful when the value in the middle is the result of some
function call:
if 1 < foo(5) < 10: ...
In D you have to use a temporary variable:
auto aux = foo(5);
if (1 < aux && aux < 10) { ...
Bye,
bearophile
Don:
> Tragic. Can we end this madness?
> Could we give & | ^ the same precedence as ==, making
> (a & mask == b) an error, just as (a < b == c) is rejected?
> That way we could lay this common bug to rest.
You can change the dmd compiler (even D1, if you want) applying this change and
create a
Don wrote:
[snip]
Or is too late to break backwards compatibility with B ?
We can and should do it. It won't impact TDPL adversely.
A perhaps little known thing is that D doesn't allow this:
int a, b, c;
if (a < b < c) { ... }
although it's compilable code in C. The same strategy could be us
Dnia 18-06-2010 o 23:11:43 Simen kjaeraas
napisał(a):
But yes, end the madness. I fear Walter will only do it if it provably
breaks no code, though.
if (a==b & c) would be flagged as error. If it breaks loudly, that's ok.
Besides, it's not much used anyway. Ban it.
Tomek
Don wrote:
I was quite shocked to find that the reason is backwards compatibility
with the B programming language.
Surely it is important that all B code ported to D compiles correctly? :p
But yes, end the madness. I fear Walter will only do it if it provably
breaks no code, though.
I just
In the comments for bug 4077, "Bugs caused by bitwise operator precedence"
it was asked why C gave & with lower precedence than ==, when it is
unintuitive and a frequent source of bugs.
I was quite shocked to find that the reason is backwards compatibility
with the B programming language.
De
96 matches
Mail list logo
