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>, 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
