> On Jan 23, 2017, at 9:14 PM, Erica Sadun via swift-evolution 
> <[email protected]> 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 
>> <[email protected] <mailto:[email protected]>> wrote:
>> 
>>> 
>>> On Jan 22, 2017, at 4:53 PM, Dave Abrahams via swift-evolution 
>>> <[email protected] <mailto:[email protected]>> wrote:
>>> 
>>> Sent from my iPad
>>> 
>>> On Jan 22, 2017, at 3:15 PM, Chris Lattner <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> 
>>>> 
>>>>> On Jan 20, 2017, at 12:22 PM, Dave Abrahams via swift-evolution 
>>>>> <[email protected] <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to