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

[Xiaodi Wu]

This is a neat idea, and I think a very sensible way to extend the
language. I worry only a little about the following:

Currently, unless preceded immediately by the keyword `fallthrough`, a
condition implicitly excludes all previous conditions. That is, if I write
`switch .. { case a: ...; case b: ...; case c: ... }`, my condition `c` is
really `!a && !b && c`. With more flexible control flow within a switch
statement, reasoning about what cases are matched by any particular
condition after the first becomes increasingly difficult.

On Sun, Jul 10, 2016 at 9:27 PM, Erica Sadun via swift-evolution <
swift-evolution at swift.org> wrote:

> A quick pitch to introduce `continue` to switch statements. This would be
> additive and could not be considered for Swift 3.
>
> -- E
>
> Pitch: Introduce continue to Switch Statements
> <https://gist.github.com/erica/04835de3d3d9121ef7308dd9b093158a#introduction>
> Introduction
>
> This pitch completes the switch statement's control flow transfer suite by
> introducing continue. Doing so provides functionality that a large
> portion of newer developers expect from (but do not get from) fallthrough.
> <https://gist.github.com/erica/04835de3d3d9121ef7308dd9b093158a#motivation>
> Motivation
>
> Swift's fallthrough statement means "continue by executing the code
> defined in the next case clause". It has at least one solid use-case, which
> is demonstrated in this example
> <https://gist.github.com/stevestreza/2557dc5ec9e7c694d7ea>
>
> Swift Evolution discussed removing fallthrough on-list in early December
> <https://lists.swift.org/pipermail/swift-evolution/2015-December/000226.html> We
> came to the consensus that fallthroughoffers sufficient utility to retain
> the feature in the language:
>
> <https://gist.github.com/erica/04835de3d3d9121ef7308dd9b093158a#the-problem-with-fallthrough>The
> Problem with Fallthrough.
>
> In Swift, fallthrough does not mean: "execute this case and then continue
> pattern matching", which is what many naive users expect. Given the
> following code where x is 5, they anticipate the function to print "5"
> and then "anything else". This is wrong. Swift prints "5" and then "6".
>
> func test(x : Int) {
>     switch x {
>     case 5:
>         print("5")
>         fallthrough
>     case 6:
>         print("6")
>     default:
>         print("anything else")
>     }
> }
>
> Fallthrough is better suited for situations like the following:
>
> case simple where even more subconditions hold: ... do complex things ...; fallthrough
> case simple where subconditions hold: ... do other things ...; fallthrough
> case simple: ... do base things ...
>
> This example produces a sieve where the most restrictive conditions
> execute specialized code and then execute code for less restrictive
> conditions.
>
> Fallthrough *cannot* be used for situations like the following example:
>
> case specialized situation 1: ... code specific to situation 1 ...; fallthrough
> case specialized situation 2: ... code specific to situation 2 ...; fallthrough
> case specialized situation 3: ... code specific to situation 3 ...; fallthrough
> case general: ... general code applicable as well to the three specialized situations ...
>
> Those coming from C-like languages might have the insight to expect
> (wrongly, it should be noted) "5", then "6", then "anything else", which is
> what you'd get with the following flawed C-ish code, where case statements
> are missing break.
>
> int x = 5;
> switch (x) {
>     case 5: NSLog(@"5"); // no break;
>     case 6: NSLog(@"6"); // no break;
>     default: NSLog(@"anything else");
> }
>
> Swift-style switch statements are more powerful and general than C-style
> switch statements. While I do not endorse C-style switch statements, I do
> think there's a case to be made for continue, which would mean "continue
> pattern matching". It would look like this:
>
> case specialized situation 1: ... code specific to situation 1 ...; continue
> case specialized situation 2: ... code specific to situation 2 ...; continue
> case specialized situation 3: ... code specific to situation 3 ...; continue
> case general: ... general code applicable as well to the three specialized situations ...
>
> In this example, code that matched general might execute any of the three
> specialized subconditions as well but would not have to fall through each
> case. So if a pattern matched scenarios 1 and 3, it would execute those
> cases and the general case, but not scenario 2.
>
> <https://gist.github.com/erica/04835de3d3d9121ef7308dd9b093158a#the-advantages-of-continue>The
> advantages of continue
>
>    - If adopted, continue allows code to execute multiple matching
>    patterns
>    - It naturally reduces code redundancy where fallthrough cannot be
>    used but code applies to multiple cases (such as the 1, 3, and general
>    example above).
>    - It uses an existing control flow transfer keyword, using it in a
>    reasonably harmonious application that isn't that far out of step with how
>    the keyword is used in other parts of the language.
>
>
> <https://gist.github.com/erica/04835de3d3d9121ef7308dd9b093158a#detailed-design>Detailed
> Design
>
> In the current design, switch statements support subset of control flow
> transfer:
>
> control-transfer-statement → break-statement
> control-transfer-statement → fallthrough-statement
> control-transfer-statement → return-statement
> control-transfer-statement → throw-statement
>
> Notably missing is "continue", which this proposal would adopt.
>
> control-transfer-statement → continue-statement
>
> The definition of continue in a switch statement would mean "after
> executing the previous statements in this case clause, continue pattern
> matching the remaining cases until a match or default is found.
>
> continue could either be disallowed in the final case (typically default)
> or could be ignored if included.
>
> <https://gist.github.com/erica/04835de3d3d9121ef7308dd9b093158a#impact-on-existing-code>Impact
> on Existing Code
>
> None.
>
> <https://gist.github.com/erica/04835de3d3d9121ef7308dd9b093158a#alternatives-considered>Alternatives
> Considered
> Not adopting this idea
>
> _______________________________________________
> 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/682d87ce/attachment.html>