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

[Jacopo Andrea Giola]

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.

Thank you very much.

- Jacopo

> On 08 Dec 2015, at 20:13, Jacopo Andrea Giola via swift-evolution <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
> 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/03c3c888/attachment.html>