> On Dec 21, 2015, at 11:57 AM, Jacopo Andrea Giola > <[email protected]> wrote: > > Hi Chris, > > 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. > 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. > It can make sense?
I’m not sure what you mean, but I’ll take a look at the other thread. -Chris > > - Jacopo > >> On 15 Dec 2015, at 22:32, Chris Lattner <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> On Dec 15, 2015, at 1:03 AM, Jacopo Andrea Giola >>> <[email protected] >>> <mailto:[email protected]>> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
