<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>If you need control flow this complex, why not just use recursion? reswitch is, near as I can tell, a recursive call to an implicitly defined function (closing over the switch).<br><br>-Colin </div><div><br>On Dec 6, 2015, at 4:49 PM, Jacopo Andrea Giola <<a href="mailto:swift-evolution@jacopo.giola.org">swift-evolution@jacopo.giola.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">The result is .Two, because you are returning from the reswitch and in that case the original x is shadowed by the new execution.</div><div class=""><br class=""></div><div class="">- Jacopo</div><br class=""><div><blockquote type="cite" class=""><div class="">On 06 Dec 2015, at 22:36, Alex Lew <<a href="mailto:alexl.mail+swift@gmail.com" class="">alexl.mail+swift@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">One question: what is the result of this code?<div class=""><br class=""></div><div class="">let x = .One</div><div class=""><br class=""></div><div class="">switch x {</div><div class="">case .One:</div><div class=""> reswitch(.Two)</div><div class="">case .Two:</div><div class=""> return x</div><div class="">}</div><div class=""><br class=""></div><div class="">.One or .Two? In other words, is x rebound inside the switch when we reswitch?</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Dec 6, 2015 at 4:28 PM, Alex Lew <span dir="ltr" class=""><<a href="mailto:alexl.mail+swift@gmail.com" target="_blank" class="">alexl.mail+swift@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">It seems reswitch <i class="">should</i> be useable even in cases that aren't a simple "goto". Or am I missing something?<div class=""><br class=""></div><div class="">For instance, rewriting the example from earlier:<div class=""><br class=""></div><div class="">switch op {</div><div class="">case let .LOAD_INDIRECT(out, in):</div><div class=""> reswitch(.LOAD(out, memory[in]))</div><div class="">case let .LOAD(out, in):</div><div class=""> setReg(out, in)</div><div class="">// ...</div><div class="">}</div><div class=""><br class=""></div><div class="">or, a switch that calculates whether some number n is in a Lisp-style list of numbers</div><div class=""><br class=""></div><div class="">switch lst {</div><div class="">case .Cons(let m, _) where m == n:</div><div class=""> return true</div><div class="">case .Cons(_, let rest):</div><div class=""> reswitch(rest)</div><div class="">case .Empty:</div><div class=""> return false</div><div class="">}</div></div><div class=""><br class=""></div><div class="">I like reswitch: in some cases, the compiler could optimize to a fallthrough, and in others, you could actually re-switch. But maybe I'm missing something.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Dec 6, 2015 at 4:14 PM, Jacopo Andrea Giola via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
Yes, I’m aware that at this time the reswitch can be abused and maybe can be better refined to disallow such cases.
</div>
<div class="">
<br class="">
</div>
<div class="">
Checking the case statement is not a problem by itself, but can be a problem if is coupled with a where clause that is not true when you fallthrought.
</div>
<div class="">
<br class="">
</div>
<div class="">
I’ve written a really bad draft here
<a href="https://gist.github.com/JGiola/f735212789bf2f697847" target="_blank" class="">https://gist.github.com/JGiola/f735212789bf2f697847</a>
</div>
<div class="">
If anyone wants to jump in and elaborate further is welcome. I will try to stay on par with this thread but I’m really bad at writing so every help is welcome.
</div>
<div class="">
<br class="">
</div>
<div class="">
And if I remember correctly Daniel Jakult was the first one to made this proposal so if he wants to take on and then made the official proposal has every right to do so and I will be very glad if my gist can be a first reference :)
</div>
<div class="">
<br class="">
</div>
<div class="">
- Jacopo
</div><div class=""><div class="">
<br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
On 06 Dec 2015, at 21:52, Colin Barrett <
<a href="mailto:colin@springsandstruts.com" target="_blank" class="">colin@springsandstruts.com</a>> wrote:
</div>
<br class="">
<div class="">
<div style="word-wrap:break-word" class="">
Apologies, Jacopo, for missing the updated proposal, and thank you for your patience in summarizing it again.
<div class="">
<br class="">
</div>
<div class="">
I’ve only glanced through it but my concern here is that it introduces a whole class of new and creative “foot-guns" :) In particular, it allows this construction to loop arbitrarily and creatively, particularly in the case of associated values.
</div>
<div class="">
<br class="">
</div>
<div class="">
I’m not sure why not checking the case statement is considered a problem for the fallthrough keyword. Assuming it’s impossible to fallthrough to a case that introduces binders (what would they be bound to?), and that this is statically checked (both of which seem reasonable assumptions to me, although if I’m wrong feel free to correct me), isn’t it the entire point of the fallthrough keyword that it skips checking the case statement? I can understand how that might be somewhat confusing (and perhaps it should be documented less prominently) but I’m not sure how it’s a *problem*, exactly...
</div>
<div class="">
<br class="">
</div>
<div class="">
I think I’m still on the side of keeping fallthrough. What’s the downside of doing nothing? For instance in the case of ++ and -- those features complicate the design of a numerics library.
</div>
<div class="">
<br class="">
</div>
<div class="">
Thanks,
</div>
<div class="">
-Colin
</div>
<div class="">
<br class="">
</div>
<div class="">
<div class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
On Dec 6, 2015, at 3:06 PM, 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 Colin,
</div>
<div class="">
<br class="">
</div>
<div class="">
the initial proposal was indeed to remove entirely the `fallthrough` keyword but many people expressed your similar concern and from that point the discussion was steered through an "enhancement" and better refinement of the keyword.
</div>
<div class="">
<br class="">
</div>
<div class="">
The new idea is to substitute the old keyword with "reswitch" passing the desired new value on which the switch is applied.
</div>
<div class="">
So something like this:
</div>
<div class="">
<br class="">
</div>
<div class="">
switch (enum) {
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>case .One:
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>// do something
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>reswitch .Two
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>case .Two:
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>// do something else
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>default:
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>// and so one
</div>
<div class="">
}
</div>
<div class="">
<br class="">
</div>
<div class="">
This new behaviour, IMO, is better suited for Swift because is more declarative of the developer intent and doesn't carry over unintentional misbehaviour.
</div>
<div class="">
Is more declarative because you are forced to state in which case you want to go, and even if the order of the switch’ cases will change in the future, you don't fall in the wrong case by mistake.
</div>
<div class="">
<br class="">
</div>
<div class="">
<div class="">
switch (enum) {
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>case .One:
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>// do something
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>reswitch .Two
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>case .OneAndAHalf
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>// maybe this change is not made by you but by a messed up merge
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>case .Two:
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>// do something else
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>default:
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>// and so one
</div>
<div class="">
}
</div>
</div>
<div class="">
<br class="">
</div>
<div class="">
In this case if you are using the fallthrough keyboard your code is now broken by accident, and depending on what are you trying to do inside the cases you can have a hidden bug that your tests are not seeing right away.
</div>
<div class="">
<br class="">
</div>
<div class="">
Another advantage is that in this way you can made more cases fallthrough in the same one even if they are not one over each other
</div>
<div class="">
<br class="">
</div>
<div class="">
<div class="">
switch (enum) {
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>case .One:
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>// do something
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>reswitch .Two
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>case .OneAndAHalf
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>// so something that you don’t want to do for .One
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>reswitch .Two
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>case .Two:
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>// do something else that you may want to do for .One and .Two
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>default:
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>// and so one
</div>
<div class="">
}
</div>
</div>
<div class="">
<br class="">
</div>
<div class="">
I must say that this is a side effect that can be used to messed up the code flow in a way that is not intended, but is a new behaviour that gives more power to the switch statement.
</div>
<div class="">
<br class="">
</div>
<div class="">
The reswitch keyword in addition is not a mere fallthrough on the new case without doing the optional checking attached to it, but is intended to be a new call and all the check are executed.
</div>
<div class="">
<br class="">
</div>
<div class="">
<div class="">
<div class="">
switch (enum) {
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>case .One:
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>// do something
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>x = 0;
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>reswitch .Two
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>case .OneAndAHalf
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>// so something that you don’t want to do for .One
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>reswitch .Two
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>case .Two where x > 0:
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>// do something else that you may want to do for .One and .Two
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>element = array[x]
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>default:
</div>
<div class="">
<span style="white-space:pre-wrap" class=""> </span>// and so one
</div>
<div class="">
}
</div>
<div class="">
(I’m going by memory and by writing this snippets in the mail app directly, so the code must be incorrect in the syntax and for this I’m sorry).
</div>
<div class="">
<br class="">
</div>
<div class="">
In this case if enum is .One the only case that is executed is case .One and the code doesn’t fallthrough in the .Two case because we are made the where invalid by changing the x to a value less than 1.
</div>
<div class="">
<br class="">
</div>
<div class="">
Now I don’t remember who was the first one who mede this proposal, and I don’t know if he is working on a first draft to lay down the things better, but for me this can be a nice improvement and a neat break with the C-switch behaviour that Swift has trying to change from the very first beta disallowing the implicit fallthrough.
</div>
<div class="">
<br class="">
</div>
<div class="">
I can be completely wrong but I see the `fallthrough`keyword as a “temporary” implementation for ease the transition from Obj-C to Swift and is time to improve it and made the switch statement even more powerful.
</div>
<div class="">
<br class="">
</div>
</div>
</div>
<div class="">
- Jacopo
<br class="">
Sent from my iPad
</div>
<div class="">
<br class="">On 06 Dec 2015, at 19:57, Colin Barrett via swift-evolution <
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:
<br class="">
<br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div class="">
<div class="">
tl;dr The fallthrough keyword, as far as I am aware, isn’t costing us anything; and has at least minimal utility, as I try to demonstrate.
</div>
</div>
<div class="">
<br class="">
</div>Apologies for jumping into this thread at an awkward point, but I’ve only just now subscribed to this list.
<div class="">
<br class="">
</div>
<div class="">
I think the fallthrough keyword is useful in certain circumstances. I’ve also yet to see an example of where it creates a negative impact, either in code, optimization, or what have you. Other than “It’s like something in C, and C is old and busted” I’m unsure of the rationale for removing it. (Feel free to point me in the right direction.)
</div>
<div class="">
<br class="">
</div>
<div class="">
Consider the Planet enum from the documentation. One of the simplest way to define the number of a planet (i.e. its 1-based index in the ordering of planets wrt. distance from the sun) is using a switch and fall-through:
</div>
<div class="">
<br class="">
</div>
<div class="">
<a href="https://gist.github.com/cbarrett/23b24a9fe76efdf006df" target="_blank" class="">https://gist.github.com/cbarrett/23b24a9fe76efdf006df</a>
</div>
<div class="">
<br class="">
</div>
<div class="">
This technique is very extensible — for instance imagine computing the force induced by the gravity of the other planets on a particular planet. All that would need to change is the case statements.
</div>
<div class="">
<br class="">
</div>
<div class="">
Yes, you could write this by putting the planets into a list and mapping or folding (or looping) over that, but unless the compiler can “unroll” that construct, you’re paying for an allocation simply bc of your choice of control flow. But in fact, you could imagine generalizing this construct into the implementation of fold for the Planet type — low-overhead folds for monomorphic types seems like a pretty compelling an natural use case for fallthrough to me.
</div>
<div class="">
<br class="">
</div>
<div class="">
Thanks,
</div>
<div class="">
-Colin
</div>
<div class="">
<br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
On Dec 6, 2015, at 4:52 AM, Jacopo Andrea Giola via swift-evolution <
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:
</div>
<br class="">
<div class="">
<div dir="auto" class="">
<div class="">
+1 for this idea, but I will prefer the reswitch keyword instead of overloading continue with a new syntax.
</div>
<div class="">
<br class="">
</div>
<div class="">
If this proposal is accepted, it must be coupled with a compiler check that the reswitch statements don't introduce an infinite "switch" loop.
</div>
<div class="">
<br class="">Sent from my iPad
</div>
<div class="">
<br class="">On 06 Dec 2015, at 00:23, Steve Canon via swift-evolution <
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:
<br class="">
<br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div class="">
Very much thinking out loud and not really the implications, I wonder if we might just use "continue" instead of "reswitch".
</div>
<div class="">
<br class="">
</div>
<div class="">
I very much like specifying what case to fall through into, no matter how we spell it.
<br class="">
<br class="">- Steve
</div>
<div class="">
<br class="">On Dec 5, 2015, at 4:45 PM, John McCall via swift-evolution <
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:
<br class="">
<br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
On Dec 5, 2015, at 1:31 PM, John McCall via swift-evolution <
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:
</div>
<div class="">
<div style="word-wrap:break-word" class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
On Dec 4, 2015, at 11:37 PM, John Calsbeek <
<a href="mailto:john.calsbeek+lists@gmail.com" target="_blank" class="">john.calsbeek+lists@gmail.com</a>> wrote:
</div>
<div class="">
<div style="word-wrap:break-word" class="">
<div class="">
<div class="">
`fallthrough` is conceptually similar to `goto` in that both allow natural expression of concepts that exist at the instruction level but are otherwise difficult to express with nested control structures. `fallthrough` is perhaps slightly less objectionable because control flow remains local, but it has a similar role.
</div>
<div class="">
<br class="">
</div>
<div class="">
It is not particularly natural to write `switch` statements with `fallthrough` in the reverse order that can be seen in Duff’s Device and similar constructs (case 7 falls through to 6 which falls through to 5, etc.). It’s just because you know for certain that all the code in case 6 would be duplicated in case 7, so 7 can transfer into 6 without a jump instruction. Communicating that to the compiler without `fallthrough` requires deeply nested `if`s.
</div>
</div>
</div>
</div>
</blockquote>
<div class="">
<br class="">
</div>Right. One idea that I’ve always had for “fallthrough” is that we might parameterize it in the future; parameterized it would mean “repeat the switch with this new value”, so that unparameterized fallthrough would mean “repeat the switch with a notional value that ends up in the next case”. There’s a very common pattern in switches of deferring to another case that I’ve always found very awkward to write in C, and while sometimes there’s no choice but to extract a helper function, there’s a still-fairly-structural code pattern here that I think we can sensibly support.
</div>
<div class="">
<br class="">
</div>
<div class="">
On the other hand, there’s an argument that this is an inappropriate extension for “fallthrough” specifically, which is one reason we’ve never pursued it.
</div>
</div>
</div>
</blockquote>
<div class="">
<br class="">
</div>Oh, I see that Joe already brought this up, spelled “reswitch”.
</div>
<div class="">
<br class="">
</div>
<div class="">
John.
</div>
<div class="">
<br class="">
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap:break-word" class="">
<div class="">
<br class="">
</div>
<div class="">
John.
</div>
<div class="">
<br class="">
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap:break-word" class="">
<div class="">
<div class="">
<br class="">
</div>
<div class="">
One defense comes to mind: there is talk of Swift aiming at systems programming. Is writing a threaded interpreter loop within the potential scope of Swift? That’s a use case that could make use of both `fallthrough` and `goto` (computed goto, really).
</div>
<div class="">
<br class="">
</div>
<div class="">
switch op {
</div>
<div class="">
case LOAD_INDIRECT:
</div>
<div class="">
in0 = memory[in1]
</div>
<div class="">
fallthrough
</div>
<div class="">
case LOAD:
</div>
<div class="">
out0 = memory[in0]
</div>
<div class="">
//...
</div>
<div class="">
}
</div>
<div class="">
<br class="">
</div>
<div class="">
I am personally interested in the prospect of a language that can scale up to high-level concepts and down to “portable assembler,” but I don’t know if that is the right direction for Swift’s evolution.
</div>
<div class="">
<br class="">
</div>
<div class="">
Cheers,
</div>
<div class="">
John
</div>
</div>
<br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
On Dec 4, 2015, at 2:42 PM, John McCall <
<a href="mailto:rjmccall@apple.com" target="_blank" class="">rjmccall@apple.com</a>> wrote:
</div>
<br class="">
<div class="">
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<blockquote type="cite" class="">
<div class="">
On Dec 4, 2015, at 2:33 PM, Kevin Ballard <
<a href="mailto:kevin@sb.org" target="_blank" class="">kevin@sb.org</a>> wrote:
</div>
<div class="">
<div class="">
<div class="">
It's not actually Duff's Device. Duff's Device relies on the fact that C switch statements don't actually introduce a new scope, and so it overlaps a switch with a do-while loop. This lets it only test the number of bytes once, to jump into the middle of the loop, and then it switches over to a while loop that decrements a counter every 8 instructions. Basically, it's a trick for manual loop unrolling that deals with non-multiple-of-8 counts efficiently.
<br class="">
</div>
</div>
</div>
</blockquote>
<div class="">
<br class="">
</div>To be pedantic, C switch statements do introduce a new scope. What Duff’s Device exploits is that switch is allowed to jump into (almost) arbitrary scopes, and cases can appear anywhere recursively inside a switch.
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<br class="">
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
But your point that Swift’s switch requires cases to be at the top level within a switch and thus prevents the use of Duff’s Device is 100% correct.
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<br class="">
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
John.
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">
<div class="">
</div>
<div class="">
Steve's code is also an example of manual loop unrolling that deals with non-multiple-of-8 counts, but it has calculate the number of bytes on every iteration instead of once. It's a good example of one of the uses of `fallthrough`, it's just not Duff's Device. It's impossible to use Duff's Device in Swift.
<br class="">
</div>
<div class="">
</div>
<div class="">
-Kevin Ballard
</div>
<div class="">
</div>
<div class="">
On Fri, Dec 4, 2015, at 02:16 PM, Greg Titus wrote:
<br class="">
</div>
<blockquote type="cite" class="">
<div class="">
Streza’s source code is an example of Duff’s Device, which is a big place where switch fallthrough is arguably the cleanest way to do things and the reason why I’d personally prefer to keep it as part of the language.
<br class="">
</div>
<div class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div class="">
On Dec 4, 2015, at 2:12 PM, Erica Sadun <
<a href="mailto:erica@ericasadun.com" target="_blank" class="">erica@ericasadun.com</a>> wrote:
<br class="">
</div>
<div class="">
</div>
<div class="">
<div style="word-wrap:break-word" class="">
<div class="">
Oh let it die, let it die. Any time I use fallthrough I find myself re-factoring to stop using it.
<br class="">
</div>
<div class="">
</div>
<div class="">
<b class="">True fact</b>: On all of
<span class=""> </span>
<a href="http://gist.github.com/" target="_blank" class="">gist.github.com</a>, there are only 22 gist results for "fallthrough language:swift".
<br class="">
</div>
<div class="">
Half of those are people just testing out the feature. Most of the remaining ones are just complex cases:
<br class="">
</div>
<div class="">
<i class="">case .Enum1, .Enum2:</i>
<br class="">
</div>
<div class="">
expressed as
<br class="">
</div>
<div class="">
<i class="">case .Enum1: fallthrough</i>
<br class="">
</div>
<div class="">
<i class="">case .Enum2:</i>
<br class="">
</div>
<div class="">
</div>
<div class="">
And then there's streza:
<a href="https://gist.github.com/stevestreza/2557dc5ec9e7c694d7ea" target="_blank" class="">https://gist.github.com/stevestreza/2557dc5ec9e7c694d7ea</a>
<span class=""> </span> I'm pretty sure that ponies were harmed in the production of whatever that last bit is.
<br class="">
</div>
<div class="">
</div>
<div class="">
</div>
<div class="">
</div>
<div class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div class="">
On Dec 4, 2015, at 3:05 PM,
<span class=""> </span>
<a href="mailto:jalkut@red-sweater.com" target="_blank" class="">jalkut@red-sweater.com</a>
<span class=""> </span>wrote:
<br class="">
</div>
<div class="">
</div>
<div class="">
<div class="">
<div class="">
In the spirit of some other proposals that remove C or C++ style artifacts, what do folks think about the possibility of removing the "fallthrough" keyword from the language?
<br class="">
</div>
<div class="">
</div>
<div class="">
My understanding is this keyword is only used for the archaic seeming purpose of perpetuating C-style fallthrough from one switch statement to the subsequent one. The documentation hedges the use of this keyword in forbidding terms that make it clear its use is not encouraged. The presence of the keyword, while an improvement over C’s implicit fallthrough, is a mark of inelegance on an otherwise well-designed, opinionated implementation of swtich statements.
<br class="">
</div>
<div class="">
</div>
<div class="">
The ugliness of fallthrough’s C-style behavior even demands a caveat in the documentation:
<br class="">
</div>
<div class="">
</div>
<div class="">
"The fallthrough keyword does not check the case conditions for the switch case that it causes execution to fall into. The fallthrough keyword simply causes code execution to move directly to the statements inside the next case (or default case) block, as in C’s standard switch statement behavior."
<br class="">
</div>
<div class="">
</div>
<div class="">
To my mind, the caveat explains just what is wrong with fallthrough, both in C or Swift: coded that is clearly labeled with deliberate conditions can nonetheless be reached.
<br class="">
</div>
<div class="">
</div>
<div class="">
I quipped about this on Twitter, and the most common pushback I got seemed to be from people who either did not know about Swift’s support for comma-separated case statements, or harbored an aesthetic preference for clustering such cases together with fallthrough statements.
<br class="">
</div>
<div class="">
</div>
<div class="">
In my opinion, unless somebody can think of a strong defense for supporting intentional fallthrough in Swift, removing the keyword would be a move in the direction of minimizing the language’s complexity while also discouraging poor coding style in switch statements.
<br class="">
</div>
<div class="">
</div>
<div class="">
Thoughts?
<br class="">
</div>
<div class="">
</div>
<div class="">
Daniel
<br class="">
</div>
<div class="">
</div>
<div class="">
_______________________________________________
<br class="">
</div>
<div class="">
swift-evolution mailing list
<br class="">
</div>
<div class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>
<br class="">
</div>
<div class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>
<br class="">
</div>
</div>
</div>
</blockquote>
</div>
<div class="">
</div>
<div class="">
<br class="">
</div>
</div>
<div class="">
_______________________________________________
<br class="">
</div>
<div class="">
swift-evolution mailing list
<br class="">
</div>
<div class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>
<br class="">
</div>
<div class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>
<br class="">
</div>
</div>
</blockquote>
</div>
<div class="">
</div>
<div class="">
<br class="">
</div>
<div class="">
<u class="">_______________________________________________</u>
<br class="">
</div>
<div class="">
swift-evolution mailing list
<br class="">
</div>
<div class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>
<br class="">
</div>
<div class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>
<br class="">
</div>
</blockquote>
<div class="">
</div>
</div>_______________________________________________
<br class="">swift-evolution mailing list
<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>
<br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>
<br class="">
</div>
</blockquote>
</div>
<br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class=""><span class=""> </span>_______________________________________________</span>
<br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">swift-evolution mailing list</span>
<br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<a href="mailto:swift-evolution@swift.org" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">swift-evolution@swift.org</a>
<br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>
</div>
</blockquote>
</div>
<br class="">
</div> _______________________________________________
<br class="">swift-evolution mailing list
<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>
<br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>
<br class="">
</div>
</blockquote>
</div>
<br class="">
</div> _______________________________________________
<br class="">swift-evolution mailing list
<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>
<br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>
<br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<blockquote type="cite" class="">
<div class="">
<span class="">_______________________________________________</span>
<br class="">
<span class="">swift-evolution mailing list</span>
<br class="">
<span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span>
<br class="">
<span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span>
<br class="">
</div>
</blockquote>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class="">
<span class="">_______________________________________________</span>
<br class="">
<span class="">swift-evolution mailing list</span>
<br class="">
<span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span>
<br class="">
<span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span>
<br class="">
</div>
</blockquote>
</div> _______________________________________________
<br class="">swift-evolution mailing list
<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>
<br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>
<br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class="">
<span class="">_______________________________________________</span>
<br class="">
<span class="">swift-evolution mailing list</span>
<br class="">
<span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span>
<br class="">
<span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span>
<br class="">
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
<div style="margin-top:10px;font-size:12px;font-family:Helvetica,Arial;color:#999" class="">
Untracked with
<a style="color:#999" href="https://trackbuster.com/?sig" target="_blank" class="">Trackbuster</a>
</div></div></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" 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=""></div>
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></blockquote></body></html>