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