[swift-evolution] Proposal: Remove the "fallthrough" keyword

[Kevin Ballard]

It's  not actually Duff's Device. Duff's Device relies on the fact that
C switch statements don't actually introduce a new scope, and so it
overlaps a switch with a do-while loop. This lets it only test the
number of bytes once, to jump into the middle of the loop, and then it
switches over to a while loop that decrements a counter every 8
instructions. Basically, it's a trick for manual loop unrolling that
deals with non-multiple-of-8 counts efficiently.

Steve's code is also an example of manual loop unrolling that deals with
non-multiple-of-8 counts, but it has calculate the number of bytes on
every iteration instead of once. It's a good example of one of the uses
of `fallthrough`, it's just not Duff's Device. It's impossible to use
Duff's Device in Swift.

-Kevin Ballard

On Fri, Dec 4, 2015, at 02:16 PM, Greg Titus wrote:
> Streza’s source code is an example of Duff’s Device, which is a big
> place where switch fallthrough is arguably the cleanest way to do
> things and the reason why I’d personally prefer to keep it as part of
> the language.
>
>> On Dec 4, 2015, at 2:12 PM, Erica Sadun <erica at ericasadun.com> wrote:
>>
>> Oh let it die, let it die. Any time I use fallthrough I find myself
>> re-factoring to stop using it.
>>
>> *True fact*: On all of gist.github.com[1], there are only 22 gist
>> results for "fallthrough language:swift". Half of those are people
>> just testing out the feature. Most of the remaining ones are just
>> complex cases: *case .Enum1, .Enum2:* expressed as *case .Enum1:
>> fallthrough* *case .Enum2:*
>>
>> And then there's streza:
>> https://gist.github.com/stevestreza/2557dc5ec9e7c694d7ea   I'm pretty
>> sure that ponies were harmed in the production of whatever that last
>> bit is.
>>
>>
>>
>>
>>> On Dec 4, 2015, at 3:05 PM, jalkut at red-sweater.com wrote:
>>>
>>> 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?
>>>
>>> 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.
>>>
>>> The ugliness of fallthrough’s C-style behavior even demands a caveat
>>> in the documentation:
>>>
>>> "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."
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Thoughts?
>>>
>>> Daniel
>>>
>>> _______________________________________________
>>> 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
>
>
> _________________________________________________
> swift-evolution mailing list swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



Links:

  1. http://gist.github.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151204/b34cc62d/attachment-0001.html>