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

[Haravikk]

I'm a bit undecided about this feature, as I think it's harder to read the switch statement. For example, with this new feature I could write something like so:

	switch x {
		case 1:
			print("1")
		case 2:
			print("2")
			continue
		case 3:
			print("3")
			continue
		default:
			print("base")
	}

But right now I can achieve this with the following:

	switch x {
		case 1:
			print("1")
		default:
			switch x {
				case 2:
					print("2")
				case 3:
					print("3")
			}
			print("base")
	}

Personally I prefer the latter; it isn't actually much more code, though it's certainly more visually noisy, but it's very explicit about what's going on, and avoids having to consider which cases will be reconsidered as the nested switch makes it very clear what it covers. Of course very complex cases may require more nesting, so become even less pretty, but personally I think the grouping outweighs this overall as it visually narrows the focus.

I wonder if perhaps there might be a way to instead simplify nested switches when operating on the same value? Is there a good real-world example that shows where a continue keyword would have clear advantage over nesting?

> On 11 Jul 2016, at 03: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/b0c498ae/attachment.html>