Swift already has a very useful goto operator that avoids the usual problems associated with arbitrary control flow. With labels and continue/break you can implement very complex control flow schemas, but still maintain structured code. I have used it at multiple occasions and this is something I absolutely adore about Swift.
— Taras > On 03 Jul 2016, at 03:27, Daryle Walker via swift-evolution > <[email protected]> wrote: > > Rust and Ada (and probably others) have a iteration statement that > specifically goes on forever, instead of using a convention of a > “while”/“repeat-until”/“for" with a never-exiting test. It’s called “loop.” > Would that be a good idea to add instead of continuing to use convention? (I > don’t know if the compiler does infinite-loop optimization, or if it can > detect it through a “while true” or similar convention.) Maybe we can label > a function “@noreturn” (or whatever) if it ends with a loop that doesn’t have > a jump statement in it (or flag an error for such loops). > > Although some consider it harmful, should we add a “goto” statement? We > would need to support labeling any statement, of course. Besides needing the > destination label to be in the same innermost function block as the goto, > what other gotchas (skipping initialization and/or destruction) do we have to > watch for? How would it interact with “guard”? I would also propose a “goto > LABEL case EXPRESSION,” where the LABEL marks a “switch” statement that > surrounds the goto statement and reevaluates the switch with the new value. > This would help with case jumping too complex for “fallthrough” to work > (including jumping FROM a “default” case). > > [I was going the ponder on generalizing the “zip2” stuff to more-than-two > sources, but that requires variadic generics and other people have already > got ideas for this.] > > Should we have double (or multiple or predicate) dispatch added? Or course, > both preferring methods to free functions and defining methods within types > (especially classes and protocols) bias for single dispatch. We would have > to switch back to preferring free functions or have some sort of “[object1, > object2].myMethod” form of dispatch. And it would go beyond what Objective-C > does (I think). > > [OK, I saw “predicate dispatch” on Wikipedia while looking up multiple > dispatch, and I don’t quite understand it (yet).] > > When I read an article at > <http://www.cocoawithlove.com/blog/2016/02/16/use_it_or_lose_it_why_safe_c_is_sometimes_unsafe_swift.html > > <http://www.cocoawithlove.com/blog/2016/02/16/use_it_or_lose_it_why_safe_c_is_sometimes_unsafe_swift.html>>, > I was surprised at Swift doesn’t make objects addressable by default. The C > family assumes being able to do this, and therefore forfeits any > optimizations from non-addressable objects. But I remembered that Ada also > does this; you have to explicitly mark objects as addressable (with the > “aliased” keyword). Should we allow users to mark objects, including blocks > of objects, as always-addressable? Or keep addressability as automatic, via > certain functions? > > — > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT mac DOT com > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
