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

[John McCall]

> On Jan 23, 2017, at 9:14 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> This was previously pitched.
> 
> https://lists.swift.org/pipermail/swift-evolution/2015-December/000231.html <https://lists.swift.org/pipermail/swift-evolution/2015-December/000231.html>
> 
> Here was the use-case that led to the thread being abandoned: 
> 
> https://gist.github.com/stevestreza/2557dc5ec9e7c694d7ea <https://gist.github.com/stevestreza/2557dc5ec9e7c694d7ea>
Additionally, it's hard to imagine us removing an innocuous language feature after promising source compatibility.  fallthrough is part of Swift now.

If there's a more general language feature that subsumes fallthrough, great, but it doesn't actually get to *eliminate* fallthrough.

John.


> 
> -- E
> 
> 
>> On Jan 22, 2017, at 11:23 PM, Russ Bishop via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On Jan 22, 2017, at 4:53 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Sent from my iPad
>>> 
>>> On Jan 22, 2017, at 3:15 PM, Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org>> wrote:
>>> 
>>>> 
>>>>> On Jan 20, 2017, at 12:22 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>>> 
>>>>>> Yeah, maybe there's a more general language feature that could replace 'fallthrough' here. Instead
>>>>>> of labelling cases, we could support a 'reswitch' statement that redispatches the switch to the case
>>>>>> matching the operand:
>>>>>> 
>>>>>>    switch some_value {
>>>>>>    case .REFINED:
>>>>>>        if !validate(some_value) { return NULL }
>>>>>>        reswitch .BASE
>>>>>> 
>>>>>>    case .BASE:
>>>>>>        handle_enum_value();
>>>>>>    }
>>>>> 
>>>>> We should just call a spade a spade and spell that "goto" ;-)
>>>> 
>>>> Goto has traditionally been used for unstructured control flow, but this form is still fully structured.  You cannot produce irreducible loops, jump into scopes, over declarations, etc.
>>> 
>>> It would be useful to know the technical definition of "structured." The fact is that there's a large category of sensible goto-like jumps that we probably want to allow and I see no advantage to giving them all distinct names.  I don't believe users will distinguish them.  We already have "break looplabel" and, aside from the label being in the wrong place, it's effectively a goto.  It seems to me we should just have goto and either prohibit the troublesome uses or give them reasonable semantics.
>>> 
>>> I could live with "break" as well as "goto", but it feels a bit like it's pretending to be something it isn't, and there's the source compatibility problem with the label position.
>>> 
>>> -Dave
>> 
>> I always assumed structured control flow means control only jumps to approved points, not arbitrary statements. Implicitly this is jumping out of a scope to a less-nested scope but never into a more-nested scope.
>> 
>> Swift takes this even further: you are limited to early exit of control flow. That’s a lot more restrictive than arbitrary goto.
>> 
>> 
>> Russ
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170124/e8b1a524/attachment.html>