<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="">Hi Owen,<div class=""><br class=""></div><div class="">I know that the examples in my proposal are very dumb and can be wrote much better without a switch, but they are here only to show what downside has the fallthrough keyword with the where clause in Swift.</div><div class=""><br class=""></div><div class="">For your second concern, in the proposal I’ve addressed the problem allowing the fallto case to be only one of the case following the one in which is declared so in your example the line fallto .One will raise a compile error because there is no .One case after case .Two</div><div class=""><br class=""></div><div class="">This infinite loop problem was already raised in an earlier proposal that is briefly addressed in the last section of the gist.</div><div class=""><br class=""></div><div class="">- Jacopo</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 09 Jan 2016, at 16:39, 肇鑫 <<a href="mailto:owenzx@gmail.com" class="">owenzx@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_default" style="font-family: georgia, serif;">Jacopo,</div><div class="gmail_default" style="font-family: georgia, serif;"><br class=""></div><div class="gmail_default" style="font-family: georgia, serif;">I have read your gist twice and try to think it over. I am afraid that I am not agree with you on this.</div><div class="gmail_default" style="font-family: georgia, serif;"><br class=""></div><div class="gmail_default" style="font-family: georgia, serif;">I think maybe your code will be more readable if you change that from switch to if clause. Maybe like this:</div><div class="gmail_default" style="font-family: georgia, serif;"><br class=""></div><div class="gmail_default" style="font-family: georgia, serif;">var x= 0</div><div class="gmail_default" style="font-family: georgia, serif;">var default = true</div><div class="gmail_default"><div class="gmail_default"><font face="georgia, serif" class="">let array = [1, 2, 3];</font></div><div class="gmail_default"><font face="georgia, serif" class="">var element = 1;</font></div><div class="gmail_default"><font face="georgia, serif" class=""><br class=""></font></div></div><div class="gmail_default" style="font-family: georgia, serif;">if .One {</div><div class="gmail_default" style="font-family: georgia, serif;">default = false</div><div class="gmail_default" style="font-family: georgia, serif;">x = 10</div><div class="gmail_default" style="font-family: georgia, serif;">}</div><div class="gmail_default" style="font-family: georgia, serif;"><br class=""></div><div class="gmail_default" style="font-family: georgia, serif;">if .Two && x >= 0 && x < array.count: {</div><div class="gmail_default" style="font-family: georgia, serif;">default = false</div><div class="gmail_default"><font face="georgia, serif" class="">element = array[x];</font><br class=""></div><div class="gmail_default" style="font-family: georgia, serif;">}</div><div class="gmail_default" style="font-family: georgia, serif;"><br class=""></div><div class="gmail_default" style="font-family: georgia, serif;">if .Three {</div><div class="gmail_default" style="font-family: georgia, serif;">default = false</div><div class="gmail_default" style="font-family: georgia, serif;">...</div><div class="gmail_default" style="font-family: georgia, serif;">}</div><div class="gmail_default" style="font-family: georgia, serif;"><br class=""></div><div class="gmail_default" style="font-family: georgia, serif;">if default {</div><div class="gmail_default" style="font-family: georgia, serif;">...</div><div class="gmail_default" style="font-family: georgia, serif;">}</div><div class="gmail_default" style="font-family: georgia, serif;"><br class=""></div><div class="gmail_default" style="font-family: georgia, serif;">Comparing to the fallThrough with fallTo, I think the prior's code is more readable and more predictable. If I am someone who tries to read some other one's code. I can quickly read the switch part as it only goes with each case alone or goes with each case and the cases below them. If the switch is written with fallTo, then I have to draw a case-map myself, or I can't figure out what may really happens. Especially if there is some thing like </div><div class="gmail_default" style="font-family: georgia, serif;"><br class=""></div><div class="gmail_default" style="font-family: georgia, serif;">case .One:</div><div class="gmail_default" style="font-family: georgia, serif;">fallTo .Two:</div><div class="gmail_default" style="font-family: georgia, serif;">case .Two:</div><div class="gmail_default" style="font-family: georgia, serif;">fallTo .One:</div><div class="gmail_default" style="font-family: georgia, serif;"><br class=""></div><div class="gmail_default" style="font-family: georgia, serif;">That leads a infinite loop. Or make the switch case unpredictable.</div><div class="gmail_default" style="font-family: georgia, serif;"><br class=""></div><div class="gmail_default" style="font-family: georgia, serif;">zhaoxin</div></div><div class="gmail_extra" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""><div class="gmail_quote">On Sat, Jan 9, 2016 at 8:08 PM, Jacopo Andrea Giola via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class="">FYI I’ve updated the gist with the draft of the proposal, <a href="https://gist.github.com/JGiola/f735212789bf2f697847" target="_blank" class="">https://gist.github.com/JGiola/f735212789bf2f697847</a></div><div class="">But I see that the discussion is pretty much death so I don’t know if it’s worth anymore to make an official request on the evolution repo…</div><div class=""><br class=""></div><div class="">- Jacopo</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 21 Dec 2015, at 22:41, Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank" class="">clattner@apple.com</a>> wrote:</div><br class=""><div class=""><div style="word-wrap: break-word;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 21, 2015, at 11:57 AM, Jacopo Andrea Giola <<a href="mailto:swift-evolution@jacopo.giola.org" target="_blank" class="">swift-evolution@jacopo.giola.org</a>> wrote:</div><br class=""><div class=""><div style="word-wrap: break-word;" class=""><div class="">Hi Chris,</div><div class=""><br class=""></div><div class="">well now after some debate in the old thread and the flaws highlighted there I’ve wrote e different proposal and narrowed the changes to only make fallthrough respect the where clause if present and to explicitly state the case where you want to fall.</div><div class="">This I think will improve the safety of the keyword and can further reduce hidden bugs in the keyword usage. The removing of fallthrough is in the title only because with the new behaviour the meaning in not correct anymore.</div><div class="">It can make sense?</div></div></div></blockquote><div class=""><br class=""></div><div class="">I’m not sure what you mean, but I’ll take a look at the other thread.</div><div class=""><br class=""></div><div class="">-Chris</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word;" class=""><div class=""><br class=""></div><div class="">- Jacopo</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 15 Dec 2015, at 22:32, Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank" class="">clattner@apple.com</a>> wrote:</div><br class=""><div class=""><div style="word-wrap: break-word;" class=""><br class=""><div class=""><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" target="_blank" class="">swift-evolution@jacopo.giola.org</a>> wrote:</div><br class=""><div class=""><div style="word-wrap: break-word;" 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 class=""><br class=""></div><div class="">Are you asking my opinion of the topic? There were two related things discussed in the thread:</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word;" 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></div></div></blockquote></div></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""><img alt="" width="1" height="1" border="0" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""></div><br class="">_______________________________________________<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" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""><br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>--<span class="Apple-converted-space"> </span><br class=""><div class="gmail_signature"><div dir="ltr" class=""><div class=""><br class="">Owen Zhao</div></div></div></div></div></blockquote></div><br class=""></div></body></html>