Re: No fall-through for switch (WAS: Re: [Submission] D Slices)
Andrej Mitrovic:
Hey I've just realized something (well, it was in the docs, doh!), we
can use already use switch case; to fallthrough to the next label
without explicitly using goto:
void main()
{
int x = 2;
switch (x)
{
case 2:
goto case; // goto case 3;
break;
case 3:
This is good to have, but I don't find this syntax easy to understand,
readable, natural. A @fallthrough is much more explicit, but it's a very
specialized thing.
Bye,
bearophile
Re: No fall-through for switch (WAS: Re: [Submission] D Slices)
Yeah I'd rather have it be something like goto next, but then this steals another keyword. Anyway you can always be explicit with your gotos if you want readability.
Re: No fall-through for switch (WAS: Re: [Submission] D Slices)
Hey I've just realized something (well, it was in the docs, doh!), we
can use already use switch case; to fallthrough to the next label
without explicitly using goto:
void main()
{
int x = 2;
switch (x)
{
case 2:
goto case; // goto case 3;
break;
case 3:
writeln(case 3);
default:
}
}
So the pain of updating the code is minimal with the new changes in place.
Re: No fall-through for switch (WAS: Re: [Submission] D Slices)
For the rare cases where fall-through is actually needed well, at least this one took off
No fall-through for switch (WAS: Re: [Submission] D Slices)
On 5/31/11 4:37 PM, Andrej Mitrovic wrote:
As for switch statements (and this is getting offtopic), there are
cases where fallback is nice to have..
final switch (param)
{
case FILE_NEW:
case FILE_OPEN:
case FILE_SAVE:
case FILE_SAVE_AS:
case EDIT_UNDO:
throw new Exception(unimplemented!); // or there would be
one method that handles these cases
case EDIT_CUT:
handleCut();
break;
case EDIT_COPY:
handleCopy();
break;
case EDIT_PASTE:
handlePaste();
break;
case EDIT_CLEAR:
handleClear();
break;
}
return 0;
If you didn't have fallback, you would probably have to add some kind
of new statement like goto next or fallback on each of those
cases.
Currently the best proposed behavior is to only require control flow if
there is actual code before it. So adjacent case labels don't require
any. Your example code would work unmodified.
For the rare cases where fall-through is actually needed, goto case xxx;
has been proposed. It has the advantage that it's robust to reordering
of labels, and the disadvantage that it's not robust to swapping label
names. Arguably, such swapping is an infrequent refactoring.
Andrei
Re: No fall-through for switch (WAS: Re: [Submission] D Slices)
I see. Well, 'goto case xxx' has the added advantage that it already works. :) I would prefer it to be just 'goto next' or something similar, but that hijacks yet another keyword. I've ever needed fallbacks after code blocks very few times, I'd be ok with the change as you've described it.
Re: No fall-through for switch (WAS: Re: [Submission] D Slices)
Andrei: Currently the best proposed behavior is to only require control flow if there is actual code before it. So adjacent case labels don't require any. Your example code would work unmodified. We have already discussed a little about this. The basic rule is to require a control flow statement at the end of each case. The special case you refer to is when there are empty case labels. I agree this special case is not going to cause bugs. In general I hate special cases, but now I have changed my mind and I now agree this one is acceptable. I hope to see such small change to D switches in a short enough time, reducing code breakage too :-) Thank you for improving D, bearophile
Re: No fall-through for switch (WAS: Re: [Submission] D Slices)
Andrei: Currently the best proposed behavior is to only require control flow if there is actual code before it. So adjacent case labels don't require any. Your example code would work unmodified. On the other hand this offers two different ways to write the same thing, because the empty ones can be already be written separated by comma: case FILE_NEW, FILE_OPEN, FILE_SAVE, FILE_SAVE_AS, case EDIT_UNDO: In Python Zen rule says: There should be one-- and preferably only one --obvious way to do it.. Bye, bearophile
