Wouldn't that be served better by `case let (x?, y?) where validate(x) && validate(y)` ?
Jacob On Sun, Jul 10, 2016 at 11:39 PM, Xiaodi Wu via swift-evolution < [email protected]> wrote: > Or, less contrived, based on code I just wrote today (and refactored, > because this doesn't work today), given two optionals a and b: > > ``` > let c: Foo? > switch (a, b) { > case let (x?, y?): > if validate(x) && validate(y) { > c = x & y // yes, bitwise and > continue > } > fallthrough > case let (x?, nil): > c = x > case let (nil, y?): > c = y > case let (nil, nil): > c = nil > fallthrough /* or, for that matter, continue */ > default: > // other stuff here that needs to be done > // unless c == x or c == y > } > ``` > > On Mon, Jul 11, 2016 at 1:11 AM, Xiaodi Wu <[email protected]> wrote: > >> switch fourSidedShape { >> case rhombus: >> // do some rhombus-specific work >> if parallelogram ~= shape { continue } >> // do some other rhombus-specific but parallelogram-inapplicable work >> fallthrough >> case rhomboid: >> // do work the slow way >> // applies to all rhomboids including rhombuses unless parallelogram >> /* implied break */ >> default: >> // now we're left with parallelograms (including rectangles and squares) >> // but in the case of non-rect parallelograms, >> // some preparatory work has been done above >> // do remaining work the fast way >> >> } >> On Mon, Jul 11, 2016 at 00:56 Erica Sadun <[email protected]> wrote: >> >>> >>> On Jul 10, 2016, at 11:54 PM, Xiaodi Wu <[email protected]> wrote: >>> >>> 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). >>> >>> 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." >>> >>> 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. >>> On Mon, Jul 11, 2016 at 00:44 Erica Sadun <[email protected]> wrote: >>> >>>> >>>> > On Jul 10, 2016, at 11:42 PM, Xiaodi Wu <[email protected]> wrote: >>>> > >>>> > 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? >>>> >>>> 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. >>>> >>>> -- E >>>> >>>> >>>> >>> Can you give me an example where anyone would ever want to say: >>> >>> case something: >>> continue >>> fallthrough >>> >>> -- E >>> >>> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
