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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
