[swift-evolution] [Pitch] Introduce continue to switch statements
Ross O'Brien
narrativium+swift at gmail.com
Mon Jul 11 05:49:15 CDT 2016
I'm in favour of this concept being available in Swift, but it does need to
make a clear distinction somewhere between a case which matches anything
(and can catch any fallthrough/continue) and a case which matches none of
the above. I don't know whether we need to introduce an explicit term for
this, or whether we make this the distinction between 'case _:' and
'default:' (with the side-effect that we can now justify 'default' in the
language).
For example: let's use this switch to play fizzbuzz.
switch value
{
case x where x % 3 == 0:
print("fizz")
continue
case x where x % 5 == 0:
print("buzz")
default:
print(value)
}
I know this is a trivial example, but it's also a frequent example used to
teach switch to programmers.
The keywords in play are 'continue' and 'default'. A multiple of 5 but not
3 will print 'buzz' and be done. A multiple of 3 and 5 will print 'fizz
buzz'. Any number not a multiple of 3 or 5 will say its value. Crucially, a
multiple of 3 but not 5 will say fizz, won't say buzz, and won't say the
number itself - whereas if we used 'case _', it would say fizz and then the
number itself.
On Mon, Jul 11, 2016 at 9:33 AM, Jacopo Andrea Giola via swift-evolution <
swift-evolution at 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
> https://gist.github.com/JGiola/f735212789bf2f697847
>
> 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 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
>
>
>
> _______________________________________________
> 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/a5164b2f/attachment.html>
More information about the swift-evolution
mailing list