On Mon, Jul 11, 2016 at 9:33 AM, Jacopo Andrea Giola via swift-evolution < swift-evolution@swift.org> wrote:
Here we go again :)
I’m obviously supporting this proposal, like the first one we had tried to
pass at the beginning of the swift evolution mailing list, even if in those
times, we try to completely replace the fallthrough keyword with a new one.
I continue to have a draft of that proposal on gist
Draft for changing the fallthorught keyword in Swift language · GitHub
Instead of continue we put out a fallto keyword that must explicit state
the case where we want to go at the end of that case, but this solution is
more clean and simple to reasoning with and use a well stated keyword used
in others flow statements.
- Jacopo
On 11 Jul 2016, at 04:27, 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
<continue.md · GitHub;
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.
<continue.md · GitHub;
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:
<continue.md · GitHub
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.
<continue.md · GitHub
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.
<continue.md · GitHub
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.
<continue.md · GitHub
on Existing Code
None.
<continue.md · GitHub
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