<div style="white-space:pre-wrap">switch fourSidedShape {<br> case rhombus:<br> // do some rhombus-specific work<br> if parallelogram ~= shape { continue }<br> // do some other rhombus-specific but parallelogram-inapplicable work<br> fallthrough<br> case rhomboid:<br> // do work the slow way<br> // applies to all rhomboids including rhombuses unless parallelogram<br> /* implied break */<br> default:<br> // now we're left with parallelograms (including rectangles and squares)<br> // but in the case of non-rect parallelograms,<br> // some preparatory work has been done above<br> // do remaining work the fast way</div><br>}<br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 11, 2016 at 00:56 Erica Sadun <<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jul 10, 2016, at 11:54 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br><div>I disagree. First, in both cases there's an A and a B. The two scenarios we are comparing are "if condition continue, else break" and "if condition continue, else fallthrough". Both break and fallthrough are equally control transfer experiments. Both of these scenarios add complexity for reasoning (compare case B and case C in my example above).<br><br>Obviously, in code, whichever of statement A or B is first reached will preclude execution of the other. But the whole point of control flow statements is to provide an expressive way to branch when necessary. If we agree that the complexity introduced by `continue` is worthwhile and useful, then "if condition continue, else fallthrough" is just as legitimate a use case as "if condition continue, else break."<br><br>As such, I'd conclude that I'm neutral on the proposal (I could do without it, but it would be intriguing and Swifty to empower the switch statement further). However, if adopted I'd strongly urge having all uses of continue permitted. Including something like `continue case 0..<2 where y < z` if a subsequent case is written as such, since after all cases are syntaxed like labels.<br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 11, 2016 at 00:44 Erica Sadun <<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Jul 10, 2016, at 11:42 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br>
><br>
> Right. Both seem equally reasonable alternatives if a condition isn't fulfilled where I'd like to continue pattern matching. Why do you say one of these would be fair to disallow?<br>
<br>
I'm saying pick behavior A or behavior B but don't do A & B because that makes computing the possibilities unnecessarily complex and I cannot think of a single real-world use-case where one would want to do both at the same time.<br>
<br>
-- E<br>
<br>
<br>
</blockquote></div>
</div></blockquote></div><br></div><div style="word-wrap:break-word"><div>Can you give me an example where anyone would ever want to say:</div><div><br></div><div>case something: </div><div> continue</div><div> fallthrough</div></div><div style="word-wrap:break-word"><div><br></div><div>-- E</div><div><br></div></div></blockquote></div>