<div dir="ltr">Wouldn't that be served better by `case let (x?, y?) where validate(x) && validate(y)` ?<div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Jacob<br></div></div></div></div>
<br><div class="gmail_quote">On Sun, Jul 10, 2016 at 11:39 PM, Xiaodi Wu via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Or, less contrived, based on code I just wrote today (and refactored, because this doesn't work today), given two optionals a and b:<br><div><br></div><div>```</div><div>let c: Foo?</div><div>switch (a, b) {</div><div>case let (x?, y?):</div><div> if validate(x) && validate(y) {</div><div> c = x & y // yes, bitwise and</div><div> continue</div><div> }</div><div> fallthrough</div><div>case let (x?, nil):</div><div> c = x</div><div>case let (nil, y?):</div><div> c = y</div><div>case let (nil, nil):</div><div> c = nil</div><div> fallthrough /* or, for that matter, continue */</div><div>default:</div><div> // other stuff here that needs to be done</div><div> // unless c == x or c == y</div><div>}</div><div>```</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 11, 2016 at 1:11 AM, Xiaodi Wu <span dir="ltr"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><div><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></div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>