I like this idea. Remember that `continue` can typically take an optional argument that allows a type of “goto” functionality. Would it work to allow the `continue` target to be a labeled `case`? This could allow for some rather sophisticated logic without needing to duplicate a lot of code and without needing to nest the switch in a loop-- especially if switching on a `var`.
An `enum` and a `switch` with targeted `continues` would make for a nice, clean state machine by updating the state in the `case` and then jumping to the right point in the selection logic. The target could be, but wouldn’t need to be the top of the `switch`. I’ve long thought that `fallthrough` should prefer a target to avoid the problems of accidentally slipping a `case` in between the `case` you’re falling out of and the `case` you’d meant to fall into. I’m not sure what the right syntax would be for the target label if the `case` uses a colon for punctuation. I suppose the label could be the `case`, but that seems verbose. The ability to insert labels inside the switch would be another advantage of wrapping the `case` statements in curly brackets though. > On Jul 10, 2016, at 19: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 > > > <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
