<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On a few occasions, fallthrough has been the most expressive path for a non-performance-related reason: rather, because it’s not possible to destructure a value and also have multiple predicates in a case, e.g.<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Menlo" class="">switch downloadStatus {</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case let .Downloading(progress) where progress == 0.0:</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>fallthrough</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case .NotStarted:</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// do things implying we have no data</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>default:</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// do things implying we have some data</font></div><div class=""><font face="Menlo" class="">}</font></div></blockquote><div class=""><div class=""><br class=""></div><div class="">Of course, we might resolve this by changing the destructuring semantics.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 4, 2015, at 2:05 PM, <a href="mailto:jalkut@red-sweater.com" class="">jalkut@red-sweater.com</a> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">In the spirit of some other proposals that remove C or C++ style artifacts, what do folks think about the possibility of removing the "fallthrough" keyword from the language?<br class=""><br class="">My understanding is this keyword is only used for the archaic seeming purpose of perpetuating C-style fallthrough from one switch statement to the subsequent one. The documentation hedges the use of this keyword in forbidding terms that make it clear its use is not encouraged. The presence of the keyword, while an improvement over C’s implicit fallthrough, is a mark of inelegance on an otherwise well-designed, opinionated implementation of swtich statements.<br class=""><br class="">The ugliness of fallthrough’s C-style behavior even demands a caveat in the documentation:<br class=""><br class="">"The fallthrough keyword does not check the case conditions for the switch case that it causes execution to fall into. The fallthrough keyword simply causes code execution to move directly to the statements inside the next case (or default case) block, as in C’s standard switch statement behavior."<br class=""><br class="">To my mind, the caveat explains just what is wrong with fallthrough, both in C or Swift: coded that is clearly labeled with deliberate conditions can nonetheless be reached.<br class=""><br class="">I quipped about this on Twitter, and the most common pushback I got seemed to be from people who either did not know about Swift’s support for comma-separated case statements, or harbored an aesthetic preference for clustering such cases together with fallthrough statements.<br class=""><br class="">In my opinion, unless somebody can think of a strong defense for supporting intentional fallthrough in Swift, removing the keyword would be a move in the direction of minimizing the language’s complexity while also discouraging poor coding style in switch statements.<br class=""><br class="">Thoughts?<br class=""><br class="">Daniel<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>