www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Switch-case made less buggy, now with PATCH!

reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3536

So Walter, with this you can keep your beloved fall-through.
Now can the rest of us be spared the nasty fall-through bugs, please
please please??

Also, about assert(0)... I'd be happy to change what I did if Walter and
associates feel that adding assert(0) to the list is worth its minor
complications.

(Sorry I don't have a patch for properties, but that one's harder.)

- Chad
Nov 20 2009
next sibling parent reply Tim Matthews <tim.matthews7 gmail.com> writes:
Chad J wrote:
 http://d.puremagic.com/issues/show_bug.cgi?id=3536
 
 So Walter, with this you can keep your beloved fall-through.
 Now can the rest of us be spared the nasty fall-through bugs, please
 please please??
 
 Also, about assert(0)... I'd be happy to change what I did if Walter and
 associates feel that adding assert(0) to the list is worth its minor
 complications.
 
 (Sorry I don't have a patch for properties, but that one's harder.)
 
 - Chad
I like having both fall through and breaking out explicit but was the final syntax ever discussed here first? Other possible options include 'fallthrough;' or just have the usual goto case for falling through too and let the compiler's optimization routines remove the unnecessary jumps when it sees the goto case as the next in sequence.
Nov 20 2009
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Tim Matthews, el 21 de noviembre a las 18:10 me escribiste:
 Chad J wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=3536

So Walter, with this you can keep your beloved fall-through.
Now can the rest of us be spared the nasty fall-through bugs, please
please please??

Also, about assert(0)... I'd be happy to change what I did if Walter and
associates feel that adding assert(0) to the list is worth its minor
complications.

(Sorry I don't have a patch for properties, but that one's harder.)

- Chad
I like having both fall through and breaking out explicit but was the final syntax ever discussed here first? Other possible options include 'fallthrough;' or just have the usual goto case for falling through too and let the compiler's optimization routines remove the unnecessary jumps when it sees the goto case as the next in sequence.
There is already goto case; (without specifying the case) for that, at least in the specs :) http://www.digitalmars.com/d/2.0/statement.html#GotoStatement GotoStatement: goto Identifier ; goto default ; goto case ; goto case Expression ; [...] The third form, goto case;, transfers to the next CaseStatement of the innermost enclosing SwitchStatement. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Every year is getting shorter never seem to find the time. Plans that either come to nought or half a page of scribbled lines. Hanging on in quiet desparation is the English way. The time is gone, the song is over, thought I'd something more to say.
Nov 20 2009
parent reply Tim Matthews <tim.matthews7 gmail.com> writes:
Leandro Lucarella wrote:
 
 There is already goto case; (without specifying the case) for that, at
 least in the specs :)
 
 http://www.digitalmars.com/d/2.0/statement.html#GotoStatement
 
 GotoStatement:
    goto Identifier ;
    goto default ;
    goto case ;
    goto case Expression ;
 
 [...]
 
 The third form, goto case;, transfers to the next CaseStatement of the
 innermost enclosing SwitchStatement.
 
Which is a very in your face explicit fall through. So we understand the advantages of making fall through explicit yet for some reason we need to have a more discreet kind of explicit syntax?
Nov 20 2009
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Tim Matthews wrote:
 
 Which is a very in your face explicit fall through. So we understand the
 advantages of making fall through explicit yet for some reason we need
 to have a more discreet kind of explicit syntax?
If it manages to make Walter happy enough to accept the patch, it's totally worth it. It makes porting the code easier too, since you don't need to know where to put the goto.
Nov 20 2009
prev sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Tim Matthews wrote:
 Chad J wrote:
 http://d.puremagic.com/issues/show_bug.cgi?id=3536

 So Walter, with this you can keep your beloved fall-through.
 Now can the rest of us be spared the nasty fall-through bugs, please
 please please??

 Also, about assert(0)... I'd be happy to change what I did if Walter and
 associates feel that adding assert(0) to the list is worth its minor
 complications.

 (Sorry I don't have a patch for properties, but that one's harder.)

 - Chad
I like having both fall through and breaking out explicit but was the final syntax ever discussed here first?
I had forgotten to add that to my test case until after I submitted the enhancement request. I've tested it now, and it seems to work fine. This works under the patch: enum Foo { a, b, } void main() { Foo blah = Foo.a; final switch(blah) { case Foo.a!: case Foo.b: break; } }
 Other possible options include 'fallthrough;' or just have the usual
 goto case for falling through too and let the compiler's optimization
 routines remove the unnecessary jumps when it sees the goto case as the
 next in sequence.
I figured this obscure token !: that no one is ever going to use for anything else will be much easier to swallow than a new keyword or a new kind of switch. I'd actually be fine with just killing fallthrough altogether, but Walter wants it (and maybe a few others too). As I ported phobos code I also realized it was much easier to just add the !: syntax to the compiler than it would have been to try and put gotos everywhere.
Nov 20 2009
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Chad J wrote:
 http://d.puremagic.com/issues/show_bug.cgi?id=3536
 
 So Walter, with this you can keep your beloved fall-through.
 Now can the rest of us be spared the nasty fall-through bugs, please
 please please??
 
 Also, about assert(0)... I'd be happy to change what I did if Walter and
 associates feel that adding assert(0) to the list is worth its minor
 complications.
 
 (Sorry I don't have a patch for properties, but that one's harder.)
 
 - Chad
Things like case A: case B: foo(); break; do not involve fallthrough bugs. If there's a bug in that code at all, it's that case A doesn't do anything. Empty case statements are not bug-prone. The thing is, that with the "goto case" syntax, D already has support for explicit fallthrough. No new syntax is required. BTW accidental fallthrough can be detected in the parse step, no semantic analysis is required, which makes it particularly easy to implement in a lint tool.
Nov 21 2009
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Don wrote:
 
 Things like
 
 case A:
 case B:
       foo();
       break;
 
 do not involve fallthrough bugs. If there's a bug in that code at all,
 it's that case A doesn't do anything. Empty case statements are not
 bug-prone.
 
My intent is not to forbid these. I suppose I've tried to damage them as little as possible. Letting them slip through without notation would do better on that count. It's a trade-off between that and easier (general) fallthrough syntax. With this syntax the code required to convert C-style switch-case to D-style becomes much easier. You can just look for case and replace : with !:. Otherwise you have to figure out where to put the goto case statement, which is usually easy enough for a human, but can be tricky for a program that doesn't have a D parser. Unless you are OK with generating some garbage: switch(foo) { case 0: switch(bar) { case 0: case 1: // but for case 2: ... } case 1: ... } becomes switch(foo) { case 0: switch(bar) { goto case 0; case 0: <-- yuck. goto case 1; case 1: // but for goto case 2; case 2: ... } goto case 1; case 1: ... } You could always just follow compiler errors though, so it's a minor point.
 The thing is, that with the "goto case" syntax, D already has support
 for explicit fallthrough. No new syntax is required.
 
I know this. Walter knows this. Why hasn't it been given emphatic thumbs up? I suspect it's because he's either busy with more important things or really enjoys fallthrough. Given how easy it is to remove implicit fallthrough and given that he's expressed a strong fondness of the fallthrough behavior, I suspect it's more the latter than the former. At any rate, I've decided to solve both. So here's a patch to make it even easier to enact (especially docs + lib migration), and also a syntax to keep fallthrough easy and compact where desired. If the syntax is a bad idea, then it can be ditched, and I'll make a new patch. All Walter has to do is say the word.
 BTW accidental fallthrough can be detected in the parse step, no
 semantic analysis is required, which makes it particularly easy to
 implement in a lint tool.
Lint tools - Don't exist for D. (AFAIK) - Add another step to my workflow/build process. The compiler should be doing this stuff anyways. So yeah, I don't really care much for lint tools. Let's just Do It Right and not need any lint tools. - Chad
Nov 21 2009
parent reply Don <nospam nospam.com> writes:
Chad J wrote:
 Don wrote:
 Things like

 case A:
 case B:
       foo();
       break;

 do not involve fallthrough bugs. If there's a bug in that code at all,
 it's that case A doesn't do anything. Empty case statements are not
 bug-prone.
My intent is not to forbid these. I suppose I've tried to damage them as little as possible Letting them slip through without notation would do better on that count. It's a trade-off between that and easier (general) fallthrough syntax.
If you think general fallthrough syntax is important, you've misunderstood the argument for this feature. See below.
 With this syntax the code required to convert C-style switch-case to
 D-style becomes much easier.  You can just look for case and replace :
 with !:.  Otherwise you have to figure out where to put the goto case
 statement, which is usually easy enough for a human, but can be tricky
 for a program that doesn't have a D parser.  Unless you are OK with
 generating some garbage:
I think you've just created the strongest argument AGAINST this feature: that it makes it too hard for machine-generated code. Forget the !: hack. No chance.
 The thing is, that with the "goto case" syntax, D already has support
 for explicit fallthrough. No new syntax is required.
I know this. Walter knows this. Why hasn't it been given emphatic thumbs up? I suspect it's because he's either busy with more important things or really enjoys fallthrough.
He made it very, very clear that he thinks that legitimate fallthrough is common. If he's right, then this whole thing is a bad idea. With something like this, you're really wasting your time making a patch for it. Patches are only worthwhile in the cases where Walter hasn't said anything, or in which he made a positive comment but nothing has happened for a long time. Once he's said something negative about a feature, providing a patch is not going to change his mind. BTW, it's _really_ difficult to get an unsolicited patch into DMD. It's happened about twice ever.
 Given how easy it is to remove implicit fallthrough and given that he's
 expressed a strong fondness of the fallthrough behavior, I suspect it's
 more the latter than the former.
 
 At any rate, I've decided to solve both.  So here's a patch to make it
 even easier to enact (especially docs + lib migration), and also a
 syntax to keep fallthrough easy and compact where desired.
 
 If the syntax is a bad idea, then it can be ditched, and I'll make a new
 patch.  All Walter has to do is say the word.
The argument for it comes down to this: "fallthrough is very rare and therefore, most uses of fallthrough are bugs". If many modifications to (say) Phobos are required, then the argument for this feature is false. From a comment someone made previously, there were about three instances of it in Phobos. If you found you needed to make many changes than that, I'll switch sides to Walter's camp. But I think you've just gone about this wrong way. Although, the "auto-generated code" argument would now need to be addressed.
Nov 21 2009
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Don wrote:
 
 I think you've just created the strongest argument AGAINST this feature:
 that it makes it too hard for machine-generated code.  Forget the !:
 hack. No chance.
 
If that's the strongest argument, then this is cake. I'll go through Phobos and insert goto case's by hand if that's what needs to happen. Most of the fallthrough I saw was stuff like this: case '1': case '2': case '3': case '4': case '5': case '6': case '7': case '8': case '9': ...etc... break; Without fallthrough this is easily rewritten as case '1': .. case '9': or case '1', '2', '3', '4', '5', '6', '7', '8', '9': Not the easiest thing to make a sed expression do, but quite obvious by hand. No !: needed. Anyhow, "hack"? "No chance."? You feel quite strongly.
 
 He made it very, very clear that he thinks that legitimate fallthrough
 is common. If he's right, then this whole thing is a bad idea.
 
 With something like this, you're really wasting your time making a patch
 for it. Patches are only worthwhile in the cases where Walter hasn't
 said anything, or in which he made a positive comment but nothing has
 happened for a long time. Once he's said something negative about a
 feature, providing a patch is not going to change his mind.
 
 BTW, it's _really_ difficult to get an unsolicited patch into DMD. It's
 happened about twice ever.
 
I feel this matters enough that I will roll the dice anyways.
 
 The argument for it comes down to this: "fallthrough is very rare and
 therefore, most uses of fallthrough are bugs".  
Not as I remember. "inline assembly is very rare and therefore, most uses of inline assembly are bugs." Such reasoning wouldn't get inline asm removed either. Fallthrough is not bad because it is rare. I think that's only mentioned because the rarity makes it easier to let go of fallthrough altogether. If many modifications to
 (say) Phobos are required, then the argument for this feature is false.
 From a comment someone made previously, there were about three instances
 of it in Phobos. If you found you needed to make many changes than that,
 I'll switch sides to Walter's camp. 
"needed". Heck no. "wanted" would be more appropriate. I could have minimized changes much more, but that costs a little in terms of the language being nice in the long term. There are way more than three fallthroughs in Phobos2. Most of it is empty cases. Axing fallthrough also axes empty cases, unless you explicitly say otherwise (and I didn't). Empty cases can be easily rewritten into equivalent code that is also clean and pleasing. I also minded the "default: assert(0);" pattern, quite common, which may or may not be fallthrough depending upon how smart the compiler wants to be. If the compiler wants to be dumb, then this becomes "default: assert(0); break;" or similar. I was being conservative and letting it be dumb. At least in dmd's case it's easy to recognize "assert(0);" as unconditional branching, so it need not be dumb. But I think you've just gone about
 this wrong way. 
Perhaps. I'll find out for myself. Also, I'll say it again in a slightly different way: I'd be fine with adding no new syntax and making a special case for empty case statements. Really I would. Although, the "auto-generated code" argument would now
 need to be addressed.
Is the auto-generated code thing really important enough to /need/ to address it? I know I mentioned it, but I also called it "a minor point". Man, I add a small nicety and it becomes some kind of uber awesome argument against the much more important issue. Sorry, I don't quite follow the logic.
Nov 22 2009
next sibling parent reply Don <nospam nospam.com> writes:
Chad J wrote:
 Don wrote:
 I think you've just created the strongest argument AGAINST this feature:
 that it makes it too hard for machine-generated code.  Forget the !:
 hack. No chance.
If that's the strongest argument, then this is cake. I'll go through Phobos and insert goto case's by hand if that's what needs to happen. Most of the fallthrough I saw was stuff like this: case '1': case '2': case '3': case '4': case '5': case '6': case '7': case '8': case '9': ...etc... break;
You didn't read my post. That is NOT bug-prone. I don't think anyone EVER makes bugs in that form. It's actually got very little in common with a true fall-through. Real fallthrough involves a 'goto' by stealth: the case introduces an entry point in the middle of a code block.
 BTW, it's _really_ difficult to get an unsolicited patch into DMD. It's
 happened about twice ever.
I feel this matters enough that I will roll the dice anyways.
Fair enough.
 
 The argument for it comes down to this: "fallthrough is very rare and
 therefore, most uses of fallthrough are bugs".  
Not as I remember. "inline assembly is very rare and therefore, most uses of inline assembly are bugs." Such reasoning wouldn't get inline asm removed either. Fallthrough is not bad because it is rare. I think that's only mentioned because the rarity makes it easier to let go of fallthrough altogether.
Not at all. Requiring changes to existing code is a very big negative to any proposal. If the number of changes required is small,
 
 If many modifications to
 (say) Phobos are required, then the argument for this feature is false.
 From a comment someone made previously, there were about three instances
 of it in Phobos. If you found you needed to make many changes than that,
 I'll switch sides to Walter's camp. 
"needed". Heck no. "wanted" would be more appropriate. I could have minimized changes much more, but that costs a little in terms of the language being nice in the long term.
 
 There are way more than three fallthroughs in Phobos2.  Most of it is
 empty cases.  Axing fallthrough also axes empty cases, unless you
 explicitly say otherwise (and I didn't).  Empty cases can be easily
 rewritten into equivalent code that is also clean and pleasing.
 
 I also minded the "default: assert(0);" pattern, quite common, which may
 or may not be fallthrough depending upon how smart the compiler wants to
 be.  If the compiler wants to be dumb, then this becomes "default:
 assert(0); break;" or similar.  I was being conservative and letting it
 be dumb.  At least in dmd's case it's easy to recognize "assert(0);" as
 unconditional branching, so it need not be dumb.
 
 But I think you've just gone about
 this wrong way. 
Perhaps. I'll find out for myself.
I doubt it.
 Also, I'll say it again in a slightly different way:  I'd be fine with
 adding no new syntax and making a special case for empty case
 statements.  Really I would.
 
 Although, the "auto-generated code" argument would now
 need to be addressed.
Is the auto-generated code thing really important enough to /need/ to address it? I know I mentioned it, but I also called it "a minor point". Man, I add a small nicety and it becomes some kind of uber awesome argument against the much more important issue. Sorry, I don't quite follow the logic.
You've missed the point. Andrei made a proposal for eliminating accidental fallthrough bugs. It didn't involve any new syntax, and changed very little existing code. Anything which violates either of those things has very little chance of acceptance. You've done a patch which completely ignores his proposal, and which violates both. The comment about the auto-generated code raises an aspect which hadn't been considered in the original proposal.
Nov 22 2009
next sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Don wrote:
 Chad J wrote:
 Don wrote:
 I think you've just created the strongest argument AGAINST this feature:
 that it makes it too hard for machine-generated code.  Forget the !:
 hack. No chance.
If that's the strongest argument, then this is cake. I'll go through Phobos and insert goto case's by hand if that's what needs to happen. Most of the fallthrough I saw was stuff like this: case '1': case '2': case '3': case '4': case '5': case '6': case '7': case '8': case '9': ...etc... break;
You didn't read my post. That is NOT bug-prone. I don't think anyone EVER makes bugs in that form. It's actually got very little in common with a true fall-through. Real fallthrough involves a 'goto' by stealth: the case introduces an entry point in the middle of a code block.
I DID read your post. I'm not saying that it is bug prone. I was just demonstrating how it is not very hard to fix code that is broken by forbidding fallthrough. I'm explaining why I don't understand how the "machine-generated" code thing is such a big issue.
 The argument for it comes down to this: "fallthrough is very rare and
 therefore, most uses of fallthrough are bugs".  
Not as I remember. "inline assembly is very rare and therefore, most uses of inline assembly are bugs." Such reasoning wouldn't get inline asm removed either. Fallthrough is not bad because it is rare. I think that's only mentioned because the rarity makes it easier to let go of fallthrough altogether.
Not at all. Requiring changes to existing code is a very big negative to any proposal. If the number of changes required is small,
continue...
 But I think you've just gone about
 this wrong way. 
Perhaps. I'll find out for myself.
I doubt it.
Ow.
 
 You've missed the point. Andrei made a proposal for eliminating
 accidental fallthrough bugs. It didn't involve any new syntax, and
 changed very little existing code. Anything which violates either of
 those things has very little chance of acceptance. You've done a patch
 which completely ignores his proposal, and which violates both.
 
Sorry I didn't know about Andrei's proposal. Buried in the NG. Why didn't you just say that Andrei made another proposal and that you're peeved I didn't use it?
 The comment about the auto-generated code raises an aspect which hadn't
 been considered in the original proposal.
I also don't get this argument against requiring code changes. D2 will break your code and is allowed to do so for the sake of progress and long term good. Everyone knows this.
Nov 22 2009
next sibling parent reply Don <nospam nospam.com> writes:
Chad J wrote:
 Don wrote:
 Chad J wrote:
 Don wrote:
 I think you've just created the strongest argument AGAINST this feature:
 that it makes it too hard for machine-generated code.  Forget the !:
 hack. No chance.
If that's the strongest argument, then this is cake. I'll go through Phobos and insert goto case's by hand if that's what needs to happen. Most of the fallthrough I saw was stuff like this: case '1': case '2': case '3': case '4': case '5': case '6': case '7': case '8': case '9': ...etc... break;
You didn't read my post. That is NOT bug-prone. I don't think anyone EVER makes bugs in that form. It's actually got very little in common with a true fall-through. Real fallthrough involves a 'goto' by stealth: the case introduces an entry point in the middle of a code block.
I DID read your post. I'm not saying that it is bug prone. I was just demonstrating how it is not very hard to fix code that is broken by forbidding fallthrough. I'm explaining why I don't understand how the "machine-generated" code thing is such a big issue.
 The argument for it comes down to this: "fallthrough is very rare and
 therefore, most uses of fallthrough are bugs".  
Not as I remember. "inline assembly is very rare and therefore, most uses of inline assembly are bugs." Such reasoning wouldn't get inline asm removed either. Fallthrough is not bad because it is rare. I think that's only mentioned because the rarity makes it easier to let go of fallthrough altogether.
Not at all. Requiring changes to existing code is a very big negative to any proposal. If the number of changes required is small,
continue...
 But I think you've just gone about
 this wrong way. 
Perhaps. I'll find out for myself.
I doubt it.
Ow.
 You've missed the point. Andrei made a proposal for eliminating
 accidental fallthrough bugs. It didn't involve any new syntax, and
 changed very little existing code. Anything which violates either of
 those things has very little chance of acceptance. You've done a patch
 which completely ignores his proposal, and which violates both.
Sorry I didn't know about Andrei's proposal. Buried in the NG.
I'm surprised about that. It's what all the recent posts were based on!
 
 Why didn't you just say that Andrei made another proposal and that
 you're peeved I didn't use it?
I'm not peeved.
 The comment about the auto-generated code raises an aspect which hadn't
 been considered in the original proposal.
I also don't get this argument against requiring code changes. D2 will break your code and is allowed to do so for the sake of progress and long term good. Everyone knows this.
Yes, but it still needs a good reason to break with C/C++/D1 in a way which increases language complexity.
Nov 22 2009
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Don wrote:
 Chad J wrote:
 Sorry I didn't know about Andrei's proposal.  Buried in the NG.
I'm surprised about that. It's what all the recent posts were based on!
Now I'm confused. http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=101110 The recent posts were in a thread that *I* started. Andrei was the first one in on the action: Andrei Alexandrescu wrote:
 Chad J wrote:
 So, switch-case statements are a frequent source of nasty bugs.  Fixing
 them (well) requires breaking backwards compatibility.

 Any chance this will happen for D2?

 (This is intended as more of a reminder and simple curiosity than a
 discussion.)
I wish very much that a transferring control flow statement (break, return, goto etc.) is required at the end of each case. Then, the rare case when you want to break through is easy to implement as goto case xxx; and all is good. Walter's answer to that has put me to silence for good. "But I use fall-through all the time!" I then knew the feature will never make it. Andrei
Agreeable words indeed, but not terribly detailed. I have to imagine you and I are looking at different things.
 Why didn't you just say that Andrei made another proposal and that
 you're peeved I didn't use it?
I'm not peeved.
"You've done a patch which completely ignores his proposal, and which violates both. " "completely ignores" and "violates". Strong words. Ya coulda fooled me. There's nothing wrong with being peeved ;)
 The comment about the auto-generated code raises an aspect which hadn't
 been considered in the original proposal.
I also don't get this argument against requiring code changes. D2 will break your code and is allowed to do so for the sake of progress and long term good. Everyone knows this.
Yes, but it still needs a good reason to break with C/C++/D1 in a way which increases language complexity.
Of course. I think we disagree on what constitutes a good reason. I'm all about reaping as many very long-term benefits as possible. Breaking a lot of code for a little gain over a long time is totally justified in my mind. (And this is a relatively small code breakage.) If D2 takes off, we might be stuck with it for many years. I'm kinda hoping D3 doesn't happen, at least not unless we have automatic D2->D3 converters and make the migration easy. I hear python did this very well. But now I'm rambling, so I'll leave it at that.
Nov 22 2009
parent Don <nospam nospam.com> writes:
Chad J wrote:
 Don wrote:
 Chad J wrote:
 Sorry I didn't know about Andrei's proposal.  Buried in the NG.
I'm surprised about that. It's what all the recent posts were based on!
Now I'm confused. http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=101110 The recent posts were in a thread that *I* started. Andrei was the first one in on the action: Andrei Alexandrescu wrote:
 Chad J wrote:
 So, switch-case statements are a frequent source of nasty bugs.  Fixing
 them (well) requires breaking backwards compatibility.

 Any chance this will happen for D2?

 (This is intended as more of a reminder and simple curiosity than a
 discussion.)
I wish very much that a transferring control flow statement (break, return, goto etc.) is required at the end of each case. Then, the rare case when you want to break through is easy to implement as goto case xxx; and all is good. Walter's answer to that has put me to silence for good. "But I use fall-through all the time!" I then knew the feature will never make it. Andrei
Agreeable words indeed, but not terribly detailed. I have to imagine you and I are looking at different things.
You're right. I think he reiterated it somewhere in that thread though. But there's been a lot of traffic recently.
 
 Why didn't you just say that Andrei made another proposal and that
 you're peeved I didn't use it?
I'm not peeved.
"You've done a patch which completely ignores his proposal, and which violates both. " "completely ignores" and "violates". Strong words. Ya coulda fooled me.
That's only because I had to say the same thing about three different times to try to get you to understand what's wrong with it. Introducing new syntax that has never been discussed is GUARANTEED to get a patch rejected. Your original patch broke all the rules, quite unnecessarily.
 There's nothing wrong with being peeved ;)
I was just doing you a favour by telling you how to write a patch that's more likely to be accepted. I don't have any personal feelings about the issue or the patch, just sick of wasting my time on something so unimportant.
Nov 22 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Chad J wrote:
 Don wrote:
 You've missed the point. Andrei made a proposal for eliminating
 accidental fallthrough bugs. It didn't involve any new syntax, and
 changed very little existing code. Anything which violates either of
 those things has very little chance of acceptance. You've done a patch
 which completely ignores his proposal, and which violates both.
Sorry I didn't know about Andrei's proposal. Buried in the NG. Why didn't you just say that Andrei made another proposal and that you're peeved I didn't use it?
Guys, guys. I don't even think I made that proposal, I'm pretty sure it has been discussed before around this newsgroup. Anyway, I think Chad's proposal has not been discussed here before being implemented, which makes it more difficult to accept. On the other hand, the fact that Chad implemented a change to switch means that he has a good understanding of the implementation, meaning he could adjust his patch to implement whichever design we all agree is suitable. Andrei
Nov 22 2009
next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Andrei Alexandrescu wrote:
 
 Guys, guys. I don't even think I made that proposal, I'm pretty sure it
 has been discussed before around this newsgroup.
 
 Anyway, I think Chad's proposal has not been discussed here before being
 implemented, which makes it more difficult to accept. On the other hand,
 the fact that Chad implemented a change to switch means that he has a
 good understanding of the implementation, meaning he could adjust his
 patch to implement whichever design we all agree is suitable.
 
 
 Andrei
Thank you, Andrei. I'm quite fine with changing the patch or even rewriting it from scratch. My meager hours are nothing compared to the grief this could save others from. - Chad
Nov 22 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 22 de noviembre a las 17:11 me escribiste:
 Anyway, I think Chad's proposal has not been discussed here before
 being implemented, which makes it more difficult to accept.
I think the exact opposite. It's much easier to accept (or reject) something that have an actual implementation. You can talk about something real, not vaporware. I wish all proposals made here were proposed with a patch. Of course that's a lot of work and people usually don't want to make the effort to write a patch if chances are it will be rejected. But if the rules are clear ("your patch can be rejected"), I think you should encourage feature proposal with proof-of-concept patch. From this thread, I really feel like you're doing the exact opposite. At least that this is my perception. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- ASALTAN, GOLPEAN SALVAJEMENTE A ANCIANA Y LE COMEN LA PASTAFROLA. -- Crónica TV
Nov 23 2009
parent reply retard <re tard.com.invalid> writes:
Mon, 23 Nov 2009 14:18:05 -0300, Leandro Lucarella wrote:

 Andrei Alexandrescu, el 22 de noviembre a las 17:11 me escribiste:
 Anyway, I think Chad's proposal has not been discussed here before
 being implemented, which makes it more difficult to accept.
I think the exact opposite. It's much easier to accept (or reject) something that have an actual implementation. You can talk about something real, not vaporware. I wish all proposals made here were proposed with a patch. Of course that's a lot of work and people usually don't want to make the effort to write a patch if chances are it will be rejected. But if the rules are clear ("your patch can be rejected"), I think you should encourage feature proposal with proof-of-concept patch.
The fact that a patch already exists does not make the design decision any better. If we all started writing crappy, contradicting extensions and Walter had to accept everything, D would quickly sink. There are only a handful of active members in this community that have enough experience and skills to propose any good features at this point of d development cycle.
Nov 23 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
retard, el 23 de noviembre a las 17:34 me escribiste:
 Mon, 23 Nov 2009 14:18:05 -0300, Leandro Lucarella wrote:
 
 Andrei Alexandrescu, el 22 de noviembre a las 17:11 me escribiste:
 Anyway, I think Chad's proposal has not been discussed here before
 being implemented, which makes it more difficult to accept.
I think the exact opposite. It's much easier to accept (or reject) something that have an actual implementation. You can talk about something real, not vaporware. I wish all proposals made here were proposed with a patch. Of course that's a lot of work and people usually don't want to make the effort to write a patch if chances are it will be rejected. But if the rules are clear ("your patch can be rejected"), I think you should encourage feature proposal with proof-of-concept patch.
The fact that a patch already exists does not make the design decision any better. If we all started writing crappy, contradicting extensions and Walter had to accept everything, D would quickly sink. There are only a handful of active members in this community that have enough experience and skills to propose any good features at this point of d development cycle.
And what I said above doesn't contradict this, on the contrary. In other OSS projects, almost the *only* way to ask for a feature is providing a patch. Then the feature is discussed (and most of the time discarded). Having a patch only improves the decision making process. Again, and in case it's hard to understand, I'm not saying the any patch should be accepted. Even more, I don't think Chad's patched should be accepted, I also think introducing case !: is a bad idea. I'm just saying that the patch was mostly turned down because he didn't asked for other devs permission to make the patch, not because of the quality of the patch (or the feature) itself. That discourages people to make patches, and I think that's *really* bad. Again, that was only my perception, maybe this was not the intention of the people who wrote the messages. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Cuando intenté arrimarle mi brazo Se puso a hablar de Miller, de Anais Nin y Picasso Y si osaba intentar robarle un beso Se ponía a leer de Neruda unos versos Me hizo mucho mal la cumbiera intelectual
Nov 23 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 retard, el 23 de noviembre a las 17:34 me escribiste:
 Mon, 23 Nov 2009 14:18:05 -0300, Leandro Lucarella wrote:

 Andrei Alexandrescu, el 22 de noviembre a las 17:11 me escribiste:
 Anyway, I think Chad's proposal has not been discussed here before
 being implemented, which makes it more difficult to accept.
I think the exact opposite. It's much easier to accept (or reject) something that have an actual implementation. You can talk about something real, not vaporware. I wish all proposals made here were proposed with a patch. Of course that's a lot of work and people usually don't want to make the effort to write a patch if chances are it will be rejected. But if the rules are clear ("your patch can be rejected"), I think you should encourage feature proposal with proof-of-concept patch.
The fact that a patch already exists does not make the design decision any better. If we all started writing crappy, contradicting extensions and Walter had to accept everything, D would quickly sink. There are only a handful of active members in this community that have enough experience and skills to propose any good features at this point of d development cycle.
And what I said above doesn't contradict this, on the contrary. In other OSS projects, almost the *only* way to ask for a feature is providing a patch. Then the feature is discussed (and most of the time discarded). Having a patch only improves the decision making process. Again, and in case it's hard to understand, I'm not saying the any patch should be accepted. Even more, I don't think Chad's patched should be accepted, I also think introducing case !: is a bad idea. I'm just saying that the patch was mostly turned down because he didn't asked for other devs permission to make the patch, not because of the quality of the patch (or the feature) itself. That discourages people to make patches, and I think that's *really* bad. Again, that was only my perception, maybe this was not the intention of the people who wrote the messages.
I understand and agree. One issue we're facing right now is that the publication of the D source is relatively recent and the number of contributors is relatively low. In this context, if we required anyone who ever wants to propose a feature to also provide a patch we'd pretty much kill the traffic on this group. I look forward to the day when that request will become reasonable. The positive side remains: Chad now knows enough about the implementation to accommodate any change to the design. At any rate, after having discussed this more with Walter, it looks like the switch semantics is here to stay. He claims to use fall through fairly often (in spite of the mounting evidence to the contrary) and finds the notion that you need to wrote "goto case x;" just before "case x:" completely stupid. I disagree but I also want to carefully pick my fights so I'll leave this matter to others. Andrei
Nov 23 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Nov 23, 2009 at 11:43 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Leandro Lucarella wrote:
 retard, el 23 de noviembre a las 17:34 me escribiste:
 Mon, 23 Nov 2009 14:18:05 -0300, Leandro Lucarella wrote:

 Andrei Alexandrescu, el 22 de noviembre a las 17:11 me escribiste:
 Anyway, I think Chad's proposal has not been discussed here before
 being implemented, which makes it more difficult to accept.
I think the exact opposite. It's much easier to accept (or reject) something that have an actual implementation. You can talk about something real, not vaporware. I wish all proposals made here were proposed with a patch. Of course that's a lot of work and people usually don't want to make the effort to write a patch if chances are it will be rejected. But if the rules are clear ("your patch can be rejected"), I think you should encourage feature proposal with proof-of-concept patch.
The fact that a patch already exists does not make the design decision any better. If we all started writing crappy, contradicting extensions and Walter had to accept everything, D would quickly sink. There are only a handful of active members in this community that have enough experience and skills to propose any good features at this point of d development cycle.
And what I said above doesn't contradict this, on the contrary. In other OSS projects, almost the *only* way to ask for a feature is providing a patch. Then the feature is discussed (and most of the time discarded). Having a patch only improves the decision making process. Again, and in case it's hard to understand, I'm not saying the any patch should be accepted. Even more, I don't think Chad's patched should be accepted, I also think introducing case !: is a bad idea. I'm just saying that the patch was mostly turned down because he didn't asked for other devs permission to make the patch, not because of the quality of the patch (or the feature) itself. That discourages people to make patches, and I think that's *really* bad. Again, that was only my perception, maybe this was not the intention of the people who wrote the messages.
I understand and agree. One issue we're facing right now is that the publication of the D source is relatively recent and the number of contributors is relatively low. In this context, if we required anyone who ever wants to propose a feature to also provide a patch we'd pretty much kill the traffic on this group. I look forward to the day when that request will become reasonable. The positive side remains: Chad now knows enough about the implementation to accommodate any change to the design. At any rate, after having discussed this more with Walter, it looks like the switch semantics is here to stay. He claims to use fall through fairly often (in spite of the mounting evidence to the contrary) and finds the notion that you need to wrote "goto case x;" just before "case x:" completely stupid. I disagree but I also want to carefully pick my fights so I'll leave this matter to others.
How would Walter feel about case continue; or continue case; ?? --bb
Nov 23 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 23 de noviembre a las 11:43 me escribiste:
Again, and in case it's hard to understand, I'm not saying the any patch
should be accepted. Even more, I don't think Chad's patched should be
accepted, I also think introducing case !: is a bad idea. I'm just saying
that the patch was mostly turned down because he didn't asked for other
devs permission to make the patch, not because of the quality of the patch
(or the feature) itself. That discourages people to make patches, and
I think that's *really* bad.

Again, that was only my perception, maybe this was not the intention of
the people who wrote the messages.
I understand and agree. One issue we're facing right now is that the publication of the D source is relatively recent and the number of contributors is relatively low. In this context, if we required anyone who ever wants to propose a feature to also provide a patch we'd pretty much kill the traffic on this group. I look forward to the day when that request will become reasonable.
I totally agree. What I'm saying is that providing patches with features request should be *encouraged*, not *required* (and certainly not discouraged! :).
 The positive side remains: Chad now knows enough about the
 implementation to accommodate any change to the design.
Sure, he might be able to change his patch in a way that has consensus.
 At any rate, after having discussed this more with Walter, it looks
 like the switch semantics is here to stay. He claims to use fall
 through fairly often (in spite of the mounting evidence to the
 contrary) and finds the notion that you need to wrote "goto case x;"
 just before "case x:" completely stupid. I disagree but I also want
 to carefully pick my fights so I'll leave this matter to others.
Well, you only have to write "goto case;", no need for the label if you only want fall-through. It's really sad that Walter dismissed this issue, even when nobody else defended the implicit fall-through and even he was proved wrong about his own frequency of use. Come on, Walter! =) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Si por el chancho fuera, se autocomería con chimichurri Worshestershire!
Nov 23 2009
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, Nov 23, 2009 at 11:33 AM, Leandro Lucarella <llucax gmail.com> wrote:
 I'm just saying
 that the patch was mostly turned down because he didn't asked for other
 devs permission to make the patch, not because of the quality of the patch
 (or the feature) itself. That discourages people to make patches, and
 I think that's *really* bad.
Don may have said that not discussing a change before submitting a patch for it dooms the patch to failure, but I don't think that's true at all. I think it just means that the chances the patch will solve the problem in a way that is agreeable to those who matter is much smaller. But if Chad had managed to hit on the magic formula that everyone thought was a great solution, I think the patch would have been accepted (after some inevitable discussion). In this case, had Chad discussed the matter first, I think he would have quickly found that there was little support for his syntax extension, and he could have saved himself the trouble of implementing it. --bb
Nov 23 2009
parent reply Don <nospam nospam.com> writes:
Bill Baxter wrote:
 On Mon, Nov 23, 2009 at 11:33 AM, Leandro Lucarella <llucax gmail.com> wrote:
 I'm just saying
 that the patch was mostly turned down because he didn't asked for other
 devs permission to make the patch, not because of the quality of the patch
 (or the feature) itself. That discourages people to make patches, and
 I think that's *really* bad.
Don may have said that not discussing a change before submitting a patch for it dooms the patch to failure, but I don't think that's true at all. I think it just means that the chances the patch will solve the problem in a way that is agreeable to those who matter is much smaller. But if Chad had managed to hit on the magic formula that everyone thought was a great solution, I think the patch would have been accepted (after some inevitable discussion).
I'm making an observation. AFAIK such patches have never been accepted.
 In this case, had Chad discussed the matter first, I think he would
 have quickly found that there was little support for his syntax
 extension, and he could have saved himself the trouble of implementing
 it.
Yes. It's such a shame, when there are so many bugs open in Bugzilla, that someone spends time on a patch which you can say apriori that it will fail. BTW, even my opDollar() patch has not recieved _any_ comment from Walter. He made a negative comment about opPow(), so at this stage it's not likely to get in. A single negative comment is typically the only feedback you'll get. In this case, Walter made a negative comment *before* the patch was made! In those circumstances, you're really wasting your time.
Nov 24 2009
parent Jason House <jason.james.house gmail.com> writes:
Don Wrote:

 Bill Baxter wrote:
 On Mon, Nov 23, 2009 at 11:33 AM, Leandro Lucarella <llucax gmail.com> wrote:
 I'm just saying
 that the patch was mostly turned down because he didn't asked for other
 devs permission to make the patch, not because of the quality of the patch
 (or the feature) itself. That discourages people to make patches, and
 I think that's *really* bad.
Don may have said that not discussing a change before submitting a patch for it dooms the patch to failure, but I don't think that's true at all. I think it just means that the chances the patch will solve the problem in a way that is agreeable to those who matter is much smaller. But if Chad had managed to hit on the magic formula that everyone thought was a great solution, I think the patch would have been accepted (after some inevitable discussion).
I'm making an observation. AFAIK such patches have never been accepted.
 In this case, had Chad discussed the matter first, I think he would
 have quickly found that there was little support for his syntax
 extension, and he could have saved himself the trouble of implementing
 it.
Yes. It's such a shame, when there are so many bugs open in Bugzilla, that someone spends time on a patch which you can say apriori that it will fail.
What's also a shame is that I've tried to solicit from Walter which changes he'd be open to. It was an attempt at getting a varied list so that inspired individuals could pick an item and run with it. For the most part, I failed. Walter did suggest two gdb compatibility issues. Andrei's response about Phobos was better, but still seemed lacking to me :( I've largely given up on trying to make things friendlier to community involvement.
Nov 24 2009
prev sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 11/22/2009 08:22 AM, Don wrote:
 You've missed the point. Andrei made a proposal for eliminating
 accidental fallthrough bugs. It didn't involve any new syntax, and
 changed very little existing code. Anything which violates either of
 those things has very little chance of acceptance. You've done a patch
 which completely ignores his proposal, and which violates both.

 The comment about the auto-generated code raises an aspect which hadn't
 been considered in the original proposal.
What was Andrei's proposal? If my memory serves (big if), he just wanted to disallow fallthrough and require use of 'goto case' when fallthrough is desired. I'm having a hard time following this discussion, but where is auto generated code an issue under this patch versus Andrei's proposal versus what we have now? And how does this patch change more code than Andrei's proposal would? I'm assuming this patch is modified to allow case 1: case 2: ...
Nov 22 2009
parent reply Don <nospam nospam.com> writes:
Ellery Newcomer wrote:
 On 11/22/2009 08:22 AM, Don wrote:
 You've missed the point. Andrei made a proposal for eliminating
 accidental fallthrough bugs. It didn't involve any new syntax, and
 changed very little existing code. Anything which violates either of
 those things has very little chance of acceptance. You've done a patch
 which completely ignores his proposal, and which violates both.

 The comment about the auto-generated code raises an aspect which hadn't
 been considered in the original proposal.
What was Andrei's proposal? If my memory serves (big if), he just wanted to disallow fallthrough and require use of 'goto case' when fallthrough is desired. I'm having a hard time following this discussion, but where is auto generated code an issue under this patch versus Andrei's proposal versus what we have now?
It's not. And how does this patch change more code than Andrei's
 proposal would?
 
 I'm assuming this patch is modified to allow
 
 case 1:
 case 2:
     ...
I wasn't. Introducing case xxx!: is the problem.
Nov 22 2009
parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 11/22/2009 05:18 PM, Don wrote:
 I wasn't. Introducing case xxx!: is the problem.
Ok, I'll bite, why is it a problem? Because it's a new syntax. Because fallthrough isn't a big enough issue to devote an entire lexical token to. Because it came out of the blue. Because instead of overhauling the entire thing and coming up with a new syntax which only executes one of the case blocks, which is what is intended 99.994% of the time, we should make arcane patches to an inherently bad design. No wait..
Nov 22 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Sun, Nov 22, 2009 at 1:50 AM, Chad J
<chadjoan __spam.is.bad__gmail.com> wrote:
 The argument for it comes down to this: "fallthrough is very rare and
 therefore, most uses of fallthrough are bugs".
Not as I remember. "inline assembly is very rare and therefore, most uses of inline assembly are bugs."
Bad analogy. It's pretty much impossible to unintentionally put some inline ASM in your code. --bb
Nov 22 2009
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Bill Baxter wrote:
 On Sun, Nov 22, 2009 at 1:50 AM, Chad J
 <chadjoan __spam.is.bad__gmail.com> wrote:
 The argument for it comes down to this: "fallthrough is very rare and
 therefore, most uses of fallthrough are bugs".
Not as I remember. "inline assembly is very rare and therefore, most uses of inline assembly are bugs."
Bad analogy. It's pretty much impossible to unintentionally put some inline ASM in your code. --bb
That's my point. I was refuting the idea that the argument for removing fallthrough was based on its rarity. Rarity has little to do with safety. Intent has everything to do with safety.
Nov 22 2009
prev sibling parent BCS <none anon.com> writes:
Hello Chad,

 Don wrote:
 
 I think you've just created the strongest argument AGAINST this
 feature: that it makes it too hard for machine-generated code.
 Forget the !: hack. No chance.
 
If that's the strongest argument, then this is cake. I'll go through Phobos and insert goto case's by hand if that's what needs to happen. Most of the fallthrough I saw was stuff like this: case '1': case '2': case '3': case '4': case '5': case '6': case '7': case '8': case '9': ...etc... break; Without fallthrough this is easily rewritten as
Without fall through, this doesn't even need to be rewritten as all the labels the "goto case;" type is forbidden, fall thought is defined where there is actual code between the labels.
Nov 24 2009
prev sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 11/20/2009 07:51 PM, Chad J wrote:
 http://d.puremagic.com/issues/show_bug.cgi?id=3536

 So Walter, with this you can keep your beloved fall-through.
 Now can the rest of us be spared the nasty fall-through bugs, please
 please please??

 Also, about assert(0)... I'd be happy to change what I did if Walter and
 associates feel that adding assert(0) to the list is worth its minor
 complications.

 (Sorry I don't have a patch for properties, but that one's harder.)

 - Chad
<patch critic> switch(i){ case 1: //this should not yield an error. change it. case 2: blah; break; } switch(i){ case 1: { break; } //this should not yield an error. change it. } switch(i){ default: blah; //this should yield an error. change it. case 0: case0onlyblah; } </patch critic>
Nov 22 2009
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Ellery Newcomer wrote:
 On 11/20/2009 07:51 PM, Chad J wrote:
 http://d.puremagic.com/issues/show_bug.cgi?id=3536

 So Walter, with this you can keep your beloved fall-through.
 Now can the rest of us be spared the nasty fall-through bugs, please
 please please??

 Also, about assert(0)... I'd be happy to change what I did if Walter and
 associates feel that adding assert(0) to the list is worth its minor
 complications.

 (Sorry I don't have a patch for properties, but that one's harder.)

 - Chad
<patch critic> switch(i){ case 1: //this should not yield an error. change it. case 2: blah; break; }
Reasonable.
 switch(i){
  case 1:
    {
      break;
    }           //this should not yield an error. change it.
 }
 
Doable. But do we want to? I think it requires semantic analysis. (Yeah I used SA for mine anyways, but mine could have be done in parse as Don mentioned.) This is a good point to mention at any rate. I forgot I had to deal with these. It's one of those things that can break code, even though it has little to do with fallthrough.
 switch(i){
   default:
     blah;      //this should yield an error. change it.
   case 0:
     case0onlyblah;
 }
 
It already does.
 
 </patch critic>
Thanks - Chad
Nov 22 2009