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.
I’ve posted an updated gist with a first early draft of the proposal with some example here: https://gist.github.com/JGiola/f735212789bf2f697847
Here a tl;dr version.
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