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.
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 :)
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@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@swift.org <mailto:swift-evolution@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.
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 :)
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@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@springsandstruts.com <mailto:colin@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@swift.org <mailto:swift-evolution@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.
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 :)
On Dec 15, 2015, at 1:03 AM, Jacopo Andrea Giola via swift-evolution <swift-evolution@swift.org> wrote:
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.
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
···
On Dec 15, 2015, at 1:03 AM, Jacopo Andrea Giola <swift-evolution@jacopo.giola.org> wrote:
Thank you very much.
- Jacopo
On 08 Dec 2015, at 20:13, Jacopo Andrea Giola via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@springsandstruts.com <mailto:colin@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@swift.org <mailto:swift-evolution@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.
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 :)
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?
- Jacopo
···
On 15 Dec 2015, at 22:32, Chris Lattner <clattner@apple.com> wrote:
On Dec 15, 2015, at 1:03 AM, Jacopo Andrea Giola <swift-evolution@jacopo.giola.org <mailto:swift-evolution@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.
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
···
On Dec 21, 2015, at 11:57 AM, Jacopo Andrea Giola <swift-evolution@jacopo.giola.org> wrote:
- Jacopo
On 15 Dec 2015, at 22:32, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
On Dec 15, 2015, at 1:03 AM, Jacopo Andrea Giola <swift-evolution@jacopo.giola.org <mailto:swift-evolution@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.
On 21 Dec 2015, at 22:41, Chris Lattner <clattner@apple.com> wrote:
On Dec 21, 2015, at 11:57 AM, Jacopo Andrea Giola <swift-evolution@jacopo.giola.org <mailto:swift-evolution@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@apple.com <mailto:clattner@apple.com>> wrote:
On Dec 15, 2015, at 1:03 AM, Jacopo Andrea Giola <swift-evolution@jacopo.giola.org <mailto:swift-evolution@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.
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;
}
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@swift.org> wrote:
On 21 Dec 2015, at 22:41, Chris Lattner <clattner@apple.com> wrote:
On Dec 21, 2015, at 11:57 AM, Jacopo Andrea Giola < > swift-evolution@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@apple.com> wrote:
On Dec 15, 2015, at 1:03 AM, Jacopo Andrea Giola < > swift-evolution@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.
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.
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
This infinite loop problem was already raised in an earlier proposal that is briefly addressed in the last section of the gist.
- Jacopo
···
On 09 Jan 2016, at 16:39, 肇鑫 <owenzx@gmail.com> wrote:
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;
}
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@swift.org <mailto:swift-evolution@swift.org>> wrote:
FYI I’ve updated the gist with the draft of the proposal, Draft for changing the fallthorught keyword in Swift language · GitHub
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@apple.com <mailto:clattner@apple.com>> wrote:
On Dec 21, 2015, at 11:57 AM, Jacopo Andrea Giola <swift-evolution@jacopo.giola.org <mailto:swift-evolution@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@apple.com <mailto:clattner@apple.com>> wrote:
On Dec 15, 2015, at 1:03 AM, Jacopo Andrea Giola <swift-evolution@jacopo.giola.org <mailto:swift-evolution@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.