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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
