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

[Xiaodi Wu]

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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/528011d3/attachment.html>