[swift-evolution] Proposal: Improve switch control flow substituting fallthrough with a more safe one

Tue Dec 15 15:32:01 CST 2015

> On Dec 15, 2015, at 1:03 AM, Jacopo Andrea Giola <swift-evolution at jacopo.giola.org> wrote:
> 
> Hi Chris,
> 
> sorry for bothering you, but during the festivity I finally have some time to work on the formal proposal draft and I’m trying to find where the switch and fallthrough behaviours are defined.
> Can you point me in the right direction? I want to see if it is feasible and fill the "Detailed design” section of the proposal with something that has some sense and can be used as a reference on how to implement the new keyword if is accepted.

Are you asking my opinion of the topic?  There were two related things discussed in the thread:

1) removing fallthrough: I found the arguments personally unconvincing.  I feel that removing fallthrough would make some important things much harder to express and uglier, potentially leading to buggier code.  I also feel that the behavior of “fallthrough” is obvious even if you’re not familiar with it, so the reasons to remove ++/— and c-style-for don’t apply.

2) on adding reswitch: It’s an interesting extension, but very narrow in applicability, and purely syntactic sugar over what we have now.  I don’t see a compelling reason to add it now, given the other higher priority things we need to make happen for swift 3.

-Chris

> 
> Thank you very much.
> 
> - Jacopo
> 
>> On 08 Dec 2015, at 20:13, Jacopo Andrea Giola via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> I had started the new proposal with repeat or reswitch in mind but the new mechanism don’t fit well with the word.
>> Now is not a new evaluation of all the switch statement (this mechanism can be exploited to create a loop inside the switch making it hard to follow for complex case) but only a “continuation” of the case evaluation that are remaining after the current one.
>> 
>> Maybe “fallto”? It indicate that the flow “fall” to cases underneath it but don’t go “trough” the optional where but just before it…
>> I don’t know, maybe someone can come up with something better :)
>> 
>> - Jacopo
>> 
>>> On 08 Dec 2015, at 19:20, Colin Barrett <colin at springsandstruts.com <mailto:colin at springsandstruts.com>> wrote:
>>> 
>>> Thanks for writing this up Jacopo! I look forward to seeing it advance through the process.
>>> 
>>> The best name I've heard so far for the keyword is "repeat" ("retry" seems too close to "try"), but I don't think it is an obvious winner just yet.
>>> 
>>> Thanks,
>>> -Colin (via thumbs)
>>> 
>>> On Dec 8, 2015, at 9:37 AM, Jacopo Andrea Giola via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> Hi everyone,
>>>> 
>>>> I’m moving this discussion in its own thread because it’s sparked inside the proposal to removing the keyword altogether without a substitution, and the wrong subject may had lead people to overlook the discussion or don’t fully understand whats going on.
>>>> 
>>>> I’ve posted an updated gist with a first early draft of the proposal with some example here: https://gist.github.com/JGiola/f735212789bf2f697847 <https://gist.github.com/JGiola/f735212789bf2f697847>
>>>> 
>>>> Here a tl;dr version.
>>>> 
>>>> After ditching the proposal to remove fallthrough some of the old participant (included me) has started to lay down the idea to substitute the keyword with a more safe one.
>>>> The reasoning behind it is that fallthrough is obviously a relic from the C past for making the switch statement in line with the C-style one and easing the tradition of C/Obj-C code to swift without altering so much in the logic.
>>>> 
>>>> In Swift thou the switch statement is more powerful and in some cases the fallthrough behaviour can lead to runtime errors that I’ve tried to list in the draft with trivial examples.
>>>> The substitute keyword will accept a value that must be matched with one of the following cases inside the switch and if a where clause is attached to it it must be fulfilled, if none of the above can be met the execution will leave the switch. The default case will only be match if the keyword will be called with `default` avoiding the unintended behaviour of a catch all.
>>>> 
>>>> In doing so we will have the same behaviour of fallthrough but in a safe way because the optional where clause will be checked and not skipped as today, and if the case specified (the case not the where) can’t be found after the keyword declaration the compiler can be raise an error.
>>>> This error can be useful if for some reason the case declaration order inside the switch is modified and the code flow created by the new keyword is altered.
>>>> 
>>>> In addition to this two new safe behaviour we can have a third one for “free”. we can have two different cases falling inside a third one without entering inside each other as  with the fallthrough.
>>>> 
>>>> I hope that this evolution can be met with the same useful discussion that the old thread has sparked and that has made me rethink the implementation from the old “reswitch” that was brought up there.
>>>> 
>>>> 
>>>> p.s. for now the new keyword is nameless because I’m not a native english speaker and I can’t come up with some word that has the correct meaning and I’m obviously open to suggestions :)
>>>> 
>>>> - Jacopo 
>>>> _______________________________________________
>>>> 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 <mailto: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/20151215/299a5c0a/attachment.html>