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

[Taras Zakharko]

There is possible impact on existing code: a switch statement inside a loop, that contains a continue.
 
— Taras

> On 11 Jul 2016, at 04:27, 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/20160711/13f13d81/attachment.html>