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

[肇鑫]

Jacopo,

I have read your gist twice and try to think it over. I am afraid that I am
not agree with you on this.

I think maybe your code will be more readable if you change that from
switch to if clause. Maybe like this:

var x= 0
var default = true
let array = [1, 2, 3];
var element = 1;

if .One {
default = false
x = 10
}

if .Two &&  x >= 0 && x < array.count: {
default = false
element = array[x];
}

if .Three {
default = false
...
}

if default {
...
}

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

case .One:
fallTo .Two:
case .Two:
fallTo .One:

That leads a infinite loop. Or make the switch case unpredictable.

zhaoxin

On Sat, Jan 9, 2016 at 8:08 PM, Jacopo Andrea Giola via swift-evolution <
swift-evolution at swift.org> wrote:

> FYI I’ve updated the gist with the draft of the proposal,
> https://gist.github.com/JGiola/f735212789bf2f697847
> 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…
>
> - Jacopo
>
> On 21 Dec 2015, at 22:41, Chris Lattner <clattner at apple.com> wrote:
>
>
> On Dec 21, 2015, at 11:57 AM, Jacopo Andrea Giola <
> swift-evolution at jacopo.giola.org> 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 <clattner at apple.com> wrote:
>
>
> 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
>
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 

Owen Zhao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160109/087e629b/attachment.html>