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@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@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 > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution