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

[Joe Groff]

> 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 <mailto:jgroff at apple.com>> wrote:
>> 
>>> 
>>> On Dec 6, 2015, at 1:14 PM, Jacopo Andrea Giola via swift-evolution <swift-evolution at swift.org <mailto: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. 

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151207/08778d21/attachment.html>