<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 15, 2015, at 1:03 AM, Jacopo Andrea Giola <<a href="mailto:swift-evolution@jacopo.giola.org" class="">swift-evolution@jacopo.giola.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Hi Chris,</div><div class=""><br class=""></div><div class="">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.</div><div class="">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.</div></div></div></div></blockquote><div><br class=""></div><div>Are you asking my opinion of the topic? There were two related things discussed in the thread:</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">Thank you very much.</div><div class=""><br class=""></div><div class="">- Jacopo</div></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 08 Dec 2015, at 20:13, Jacopo Andrea Giola via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I had started the new proposal with repeat or reswitch in mind but the new mechanism don’t fit well with the word.<div class="">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.</div><div class=""><br class=""></div><div class="">Maybe “fallto”? It indicate that the flow “fall” to cases underneath it but don’t go “trough” the optional where but just before it…</div><div class="">I don’t know, maybe someone can come up with something better :)</div><div class=""><br class=""></div><div class="">- Jacopo<div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 08 Dec 2015, at 19:20, Colin Barrett <<a href="mailto:colin@springsandstruts.com" class="">colin@springsandstruts.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">Thanks for writing this up Jacopo! I look forward to seeing it advance through the process.</div><div class=""><br class=""></div><div class="">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.<br class=""><br class="">Thanks,<br class="">-Colin (via thumbs)</div><div class=""><br class="">On Dec 8, 2015, at 9:37 AM, Jacopo Andrea Giola via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">Hi everyone,</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">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.</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">I’ve posted an updated gist with a first early draft of the proposal with some example here: </span><a href="https://gist.github.com/JGiola/f735212789bf2f697847" style="font-family: Menlo-Regular; font-size: 11px;" class="">https://gist.github.com/JGiola/f735212789bf2f697847</a><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">Here a tl;dr version.</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">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.</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">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.</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">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.</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">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.</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">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.</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">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.</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">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.</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">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.</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">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 :)</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">- Jacopo</span>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=CE9t65EUurFM3C3-2FZuqa1cBtZWwfe39uo7qQti09cYZieoEOQ5dJL7ADIGaaRAOnItkMg1MoCFeWp5pnFeThtsN-2FLaufkqMIYhixoKNKN-2Fjqcz9lKlRYAcI0U-2FacxRoKBU4m6JTrfKqGk78WS0uJqAwaHCpsal7NyzAog-2FF2vuhhf0Qtd4yoEOyQKPdXOi4bl4KN7Bz4LglH-2BixlAlaXsHYpTWU0kWCKJj2WS-2BPg1pA-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=amyhbYWPIxEqpemwz9EpIz-2FncXlpeQcbw9HufCiUnRDiW6oVOtJG3w63BsLZ4LdRpi-2Bmfr44HbfEkAwl6rl1F-2FFBjmi92Pmcra-2Bv8FB4l7-2FDZOlV2Y3-2FuMffoBiAVeUgCTkzVhRoRKl-2BjWsAquNAeYMS4CW41mIQ7Yztwj-2BN2aScO4FoKNqEsJmP4iGc7GlZch7dzuwvdFaUfHB-2BOmYLoz-2FxWTqNKM6gg2dFECWaXd-2FwwTOuFkFlm-2Fbk-2B9qVO0M4" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>