[swift-evolution] [Pitch] Introduce continue to switch statements

[Jacob Bandes-Storch]

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 <
swift-evolution at swift.org> 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 <xiaodi.wu at gmail.com> 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 <erica at ericasadun.com> wrote:
>>
>>>
>>> On Jul 10, 2016, at 11:54 PM, Xiaodi Wu <xiaodi.wu at gmail.com> 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 <erica at ericasadun.com> wrote:
>>>
>>>>
>>>> > On Jul 10, 2016, at 11:42 PM, Xiaodi Wu <xiaodi.wu at gmail.com> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160710/3f57a57a/attachment.html>