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

[Colin Barrett]

> On Dec 7, 2015, at 1:43 PM, Joe Groff <jgroff at apple.com> wrote:
> 
> 
>>> On Dec 7, 2015, at 12:38 PM, Colin Barrett <colin at springsandstruts.com> wrote:
>>> 
>>> 
>>>> On Dec 7, 2015, at 8:55 AM, Joe Groff <jgroff at apple.com> wrote:
>>>> 
>>>> 
>>>> On Dec 6, 2015, at 1:14 PM, Jacopo Andrea Giola via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> Yes, I’m aware that at this time the reswitch can be abused and maybe can be better refined to disallow such cases.
>>> 
>>> Infinite reswitch loops seem useful. I'm thinking in particular of interpreter loops, where it's common to use GCC's computed goto extension when written in C.
>> 
>> I agree that they have useful semantics; I just wonder if it’s more clear to have explicit recursion (with TCO ;) rather than to add a looping construct that effectively does the same thing...
>> 
>> Can’t lie though, given the lack of TCO in Swift, a keyword like this would probably mean fewer stack frames in code I’ve written myself (for instance, a parser combinator library).
> 
> Semantically they're equivalent, but you're putting more into the optimizer's hands than many would feel comfortable with. TCO notwithstanding, the naive CFG that results from a self-recursive call still funnels the switch dispatch jump into the top of the loop, which means you're sharing one branch predictor slot for every "reswitch". This is one of the main reasons computed goto exists in GCC instead of letting people just use 'switch x { }; unreachable()'. An explicit "reswitch" could emit the rebranch in-line at the reswitch point. 

I took a look at the manual for computed goto, and I think I understand now. Instead of  always branching back the top of the switch, you can branch directly to whichever case you know you need to go to -- the branch is now entirely computed at the call site, instead of indirecting thru the (recursive) callee. Thanks Joe!

-Colin (via thumbs)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151207/cefcefe9/attachment.html>