<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 17 February 2014 06:03, Walter Bright <span dir="ltr"><<a href="mailto:newshound2@digitalmars.com" target="_blank">newshound2@digitalmars.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On 2/16/2014 7:42 AM, Manu wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
1. case fall-through is not supported; explicit 'goto case n;' is required.<br></div><div class="">
With this in mind, 'break' is unnecessary. Why is it required?<br>
</div></blockquote>
<br>
It's that way to prevent confusion from people used to C/C++, and/or transliterating code from such to D.</blockquote><div><br></div><div>I figured that, but deliberately gimping a construct that could be far more useful than it is, just because it was crap in some other language seems like a poor choice to me.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
2. 'case 1, 3, 7, 8:' is awesome! ...but ranged cases have a totally different<br>
syntax: 'case 1: .. case 3:'<br>
<br>
Why settle on that syntax? The inconsistency looks kinda silly when they appear<br>
together in code.<br>
Surely it's possible to find a syntax that works without repeating case and ':'?<br>
</blockquote>
<br></div>
Many syntaxes were proposed for that, and this was the best one.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'm not sure it's reasonable to use the '..' syntax in this case for that<br>
reason. '..' is an [) range, case ranges must be [] so that it makes sense when<br>
dealing with enum key ranges.<br>
</blockquote>
<br></div>
That was the known problem with using a..b</blockquote><div><br></div><div>Yeah, but when I suggest a..b, I suggest applying existing [) range rules, as would be expected.</div><div><br></div><div>It doesn't make sense for enum keys, and I think the existing syntax is acceptable for [] usage with enum keys, but you're not always switching on enums.</div>
<div>Perhaps supporting both would be useful, where a..b is [) as expected, and 'case A: .. case B:' is [] for use with enums?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
3. Why is 'default' necessary? If I'm not switching on an enumerated type, then<br>
many values are meaningless. requiring an empty 'default: break;' line at the<br>
end is annoying and noisy.<br>
</blockquote>
<br></div>
It originally was not required, but there was a campaign by a lot of D users to make it required to deal with the common bug of adding a value in one switch statement but forgetting to add it to another corresponding one.</blockquote>
<div><br></div><div>Isn't that the entire point of final switch?</div><div>Why introduce final switch to address that, then do this aswell?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
if not for these strange decisions (purely for legacy compliance?).<br>
</blockquote>
<br></div>
I hope you'll find them less strange now.<br></blockquote><div><br></div><div>Well, I get them, but it seems like an awful lot of missed opportunities. D threatens to improve substantially on C switch, but it only goes half way, resulting in something that's only slightly nicer if used precisely in the 'C way'. </div>
<div>It doesn't offer any new use cases, which is only really inhibited by some quite trivial decisions.</div><div><br></div><div>Maybe a new and improved syntax for D that can be lowered?</div><div>'select()'? 'match()'?</div>
<div><br></div><div>I would set it up with proper scoping syntax:</div><div>match([x =] expression)</div><div>{</div><div>  case(1, 3, 4, 6) // use parentheses like all other control statements?</div><div>  {</div><div>    proper scope block...</div>
<div>    goto named_case;</div><div>  }</div><div><br></div><div><div>  case(10..20) // [) interval</div><div>    singleStatement();</div></div><div><br></div><div>  case(2, 5, 7..10) // this would be handy too</div><div>
    singleStatement();</div><div>    </div><div>  case named_case // it's a useful concept; explicit named case for shared work, which others can jump to. not sure how best to express it...</div><div>    sharedOperation();</div>
<div><br></div><div>  default</div><div>  {</div><div>    // surely this should be optional?</div><div>  }</div><div>}</div><div><br></div><div>I think a really useful construct could be made out of switch, but it seems that it won't happen because it must support C code unchanged.</div>
</div></div></div>