Don wrote:
> 
> But 'goto case XXX' is an extremely rarely encountered construct, that screams 'Examine this code closely'. So I don't think it needs extra error checking.

Oh, I don't think that it's a big issue. We have "goto case XXX" and "goto case," so we could use them to enforce flow control statements at the end of case blocks without changing anything other than what the compiler complains about. I definitely think that "continue switch" is less error prone than "goto case," and I'd prefer "continue switch," but "goto case XXX" is indeed rare enough that the frequency of screwing up and using "goto case" instead of "goto case XXX" would be quite small. So, I definitely find "continue switch" to be preferable, but it's not a big deal.

- Jonathan M Davis

Jonathan M Davis Wrote:

> Sean Kelly wrote:
> > 
> > It's a small thing, but I think "continue switch" could be misleading. Consider this:
> > 
> > switch (getState()) {
> > case X:
> >     setState(Z);
> >     continue switch;
> > case Y:
> >     break;
> > case Z:
> >     writeln( "done!" );
> > }
> > 
> > Having never encountered D before, what would be your interpretation of this code?
> 
> I hadn't thought of that. That could be a source of confusion. However, since a switch statement isn't a loop, and it's not a construct in any other language AFAIK, the person will look it up
...
> Personally, I think that the fact that it's less error prone alone makes it a better choice even if it were somewhat less clear.

I'm inclined to agree.  This is just the first thing that popped into my mind when I saw "continue switch" and I figured I'd bring it up.

On 06/21/2010 04:15 PM, Don wrote:
> Jonathan M Davis wrote:
>> Sean Kelly wrote:
>>
>>> Jonathan M Davis Wrote:
>>>> In any case, that means that it could be made required to have a
>>>> control
>>>> statement at the end of a case block without having to specify a
>>>> specific
>>>> destination for fallthrough - though I'd prefer "continue switch" over
>>>> "goto case" since it's more explicit and less error prone (since
>>>> there's
>>>> no doubt that you didn't intend to put a destination for the goto if
>>>> you
>>>> use "continue switch" instead of a "goto case" without a destination).
>>> It's a small thing, but I think "continue switch" could be
>>> misleading. Consider this:
>>>
>>> switch (getState()) {
>>> case X:
>>> setState(Z);
>>> continue switch;
>>> case Y:
>>> break;
>>> case Z:
>>> writeln( "done!" );
>>> }
>>>
>>> Having never encountered D before, what would be your interpretation of
>>> this code?
>>
>> I hadn't thought of that. That could be a source of confusion.
>> However, since a switch statement isn't a loop, and it's not a
>> construct in any other language AFAIK, the person will look it up.
>> Once you've looked it up, I don't think that it would be particularly
>> hard to remember what it actually does. It's quite clear what's going
>> once you've become familiar with the construct and is quite
>> unambiguous in comparison to "goto case" which could easily be missing
>> the target case rather than being meant for fallthrough.
>>
>> So, perhaps it's not immediately intuitive, but many language
>> constructs are, and I think that it's fairly clear once you've looked
>> it up. Having something like "fallthrough" or "goto next case" would
>> of course be even clearer, but those would require new keywords. I
>> still think that "continue switch" would be clearer than "goto case"
>> as well as less error prone. Personally, I think that the fact that
>> it's less error prone alone makes it a better choice even if it were
>> somewhat less clear.
>>
>> - Jonathan M Davis
>
> But 'goto case XXX' is an extremely rarely encountered construct, that
> screams 'Examine this code closely'. So I don't think it needs extra
> error checking.

After Sean's example, goto case XXX is my fave for fallthrough. I don't like unlabeled "goto case" to mean fall through, it's one of those "need to look in the manual" features. goto case XXX is generalized fall through.

Andrei

Andrei Alexandrescu wrote:
> 
> After Sean's example, goto case XXX is my fave for fallthrough. I don't like unlabeled "goto case" to mean fall through, it's one of those "need to look in the manual" features. goto case XXX is generalized fall through.
> 
> Andrei

Well, it definitely works, but then you run into the issue of whether you used the right XXX. That's the kind of place that rearranging code is likely to run into bugs whereas "goto case" by itself or "continue switch" would just fall through. It also makes it less obvious when you have errors with "goto case XXX" being intended to jump somewhere other than the next case. If you're using a statement that is explicitly for falling through, then it's clearly differentiated from a statement where you're jumping to a case other than the next one. I can't say that I'm terribly found of "goto case" by itself, but at least it would be less likely to cause bugs when rearranging code and more clearly indicates the intention to fall through. It still isn't as good a statement which can only be used for fallthrough (and therefore couldn't be a "goto case" where you were supposed to put a target but didn't), but I see no advantage in using "goto case XXX" for fallthrough instead of "goto case".

"goto case" does seem a bit silly, but I think that it's clearer and less error prone for anyone who understands "goto case." The only issue is the fact that it would be odd for someone who didn't know that you could do that, but there's plenty of that to go around already, and it's not like it would be hard to remember when you see it if you've already looked it up.

- Jonathan M Davis

On 06/21/2010 06:01 PM, Jonathan M Davis wrote:
> Andrei Alexandrescu wrote:
>>
>> After Sean's example, goto case XXX is my fave for fallthrough. I don't
>> like unlabeled "goto case" to mean fall through, it's one of those "need
>> to look in the manual" features. goto case XXX is generalized fall
>> through.
>>
>> Andrei
>
> Well, it definitely works, but then you run into the issue of whether you
> used the right XXX. That's the kind of place that rearranging code is likely
> to run into bugs whereas "goto case" by itself or "continue switch" would
> just fall through.

Here's where statistics come forward:

- code that uses fall through: rare

- code that uses fall through and needs to be rearranged: rare * rare

- code that uses fall through, needs to be rearranged, and the rearranger doesn't even look at the statement IMMEDIATELY PRECEDING the moved case label: rare * rare * rare

We're looking at three orders of magnitude here. I think it's reasonable to not dedicate too much language design to this case.

> It also makes it less obvious when you have errors with
> "goto case XXX" being intended to jump somewhere other than the next case.

Example that may actually refer to real-world code?

Even Duff's device will have a sensible definition, albeit more verbose (which is GOOD): each label action will end with "goto case that_label-1".

> If you're using a statement that is explicitly for falling through, then
> it's clearly differentiated from a statement where you're jumping to a case
> other than the next one.

I have zero empathy with that distinction. On the contrary, I think code should be written in terms of going from one label handler to another, instead of falling into whatever comes next.

> I can't say that I'm terribly found of "goto case"
> by itself, but at least it would be less likely to cause bugs when
> rearranging code and more clearly indicates the intention to fall through.

Zero.Empathy.

> It still isn't as good a statement which can only be used for fallthrough
> (and therefore couldn't be a "goto case" where you were supposed to put a
> target but didn't), but I see no advantage in using "goto case XXX" for
> fallthrough instead of "goto case".

I see no disadvantage, and on the contrary, many disadvantages for the cryptic "goto case". (What if it means go again to the current case?)

The problem is, if Walter sees us bickering too much, he'll use that as pretext to veto out any improvement.

> "goto case" does seem a bit silly, but I think that it's clearer

No clarity for me.

> and less
> error prone for anyone who understands "goto case."

I don't see that.

> The only issue is the
> fact that it would be odd for someone who didn't know that you could do
> that, but there's plenty of that to go around already, and it's not like it
> would be hard to remember when you see it if you've already looked it up.

Yeah, but it's not like we want to add such cases without necessity.


Andrei

On 06/21/2010 05:11 PM, Jonathan M Davis wrote:
>
> Having something like "fallthrough" or "goto next case" would of
> course be even clearer, but those would require new keywords.

I think "fallthrough" would be a perfect keyword to add here. C programmers will immediately recognize it. Switch/case are already specialized keywords, and fallthrough can complete the set. It's unlikely to conflict with existing source, and this is one case where having a conspicuously long keyword is a good thing.

Finally, goto is ugly and continue is strongly associated with looping.

Andrei Alexandrescu wrote:

[snip]
> 
> 
> Andrei

Well, "goto case" and "goto case XXX" both already exist. Both get the job done. So, regardless of which would be better for fallthrough, we can choose to use whichever we want in our code. As it stands, it becomes a matter of preference. I'd love something like "continue switch" or "fallthrough" to indicate explicit fallthrough, but it isn't at all necessary, so it's not worth trying to get Walter to add anything like that.

At this point, if Walter makes it so that case blocks must end with a flow control statement of some kind, we're free to use either "goto case" or "goto case XXX" for fallthrough, so unless "goto case" is so bad that we should try to get Walter to get rid of it, I don't think that it's really an issue. We can use whichever one we want and not worry about it. The language is complete enough to require case statements to end with a control statement without losing any flexibility, so I think that we can agree to disagree on which statement is better and/or clearer and try and get Walter to add the compiler error for naked fallthrough.

- Jonathan M Davis

Andrei Alexandrescu:
> The problem is, if Walter sees us bickering too much, he'll use that as pretext to veto out any improvement.

You are wrong, Walter is an adult able to understand discussions, not a capricious dictator :-) Syntax and other things require discussions, sometimes even longish ones.

Bye,
bearophile

bearophile wrote:

> Andrei Alexandrescu:
>> The problem is, if Walter sees us bickering too much, he'll use that as pretext to veto out any improvement.
> 
> You are wrong, Walter is an adult able to understand discussions, not a capricious dictator :-) Syntax and other things require discussions, sometimes even longish ones.
> 
> Bye,
> bearophile

Yes, he's an adult, but if he's not particularly interested in the change to begin with, and the folks who want the change can't agree on what the change should be, he could easily choose to leave things as they are - especially because things work just fine as they are. We'd like to be able to make a particular error harder to make, but it's not exactly a groundbreaking change. Walter could decide to work on more important things rather than worrying about this one. There's nothing childish about that.

- Jonathan M Davis

Did anyone suggest "continue case" instead of "continue switch"?  That sounds less ambiguous to me.

--bb

On Mon, Jun 21, 2010 at 4:56 PM, Jonathan M Davis <jmdavisProg@gmail.com> wrote:
> Andrei Alexandrescu wrote:
>
> [snip]
>>
>>
>> Andrei
>
> Well, "goto case" and "goto case XXX" both already exist. Both get the job done. So, regardless of which would be better for fallthrough, we can choose to use whichever we want in our code. As it stands, it becomes a matter of preference. I'd love something like "continue switch" or "fallthrough" to indicate explicit fallthrough, but it isn't at all necessary, so it's not worth trying to get Walter to add anything like that.
>
> At this point, if Walter makes it so that case blocks must end with a flow control statement of some kind, we're free to use either "goto case" or "goto case XXX" for fallthrough, so unless "goto case" is so bad that we should try to get Walter to get rid of it, I don't think that it's really an issue. We can use whichever one we want and not worry about it. The language is complete enough to require case statements to end with a control statement without losing any flexibility, so I think that we can agree to disagree on which statement is better and/or clearer and try and get Walter to add the compiler error for naked fallthrough.
>
> - Jonathan M Davis
>