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
Something like this was discussed at one point; I believe people referred to it as `reswitch`.
In general, you're not going to get very far by naming a bunch of features and asking if we should have them. Show us motivating examples. Help us understand what you want them for. (And if you don't know why you'd want them, well, why are you proposing them?)
···
On Jul 2, 2016, at 6:27 PM, Daryle Walker via swift-evolution <swift-evolution@swift.org> wrote:
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).
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 <swift-evolution@swift.org> 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>, 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