[swift-evolution] Proposal: "break for", "break do", "break if", "break case", "break repeat", etc.

[Austin Zheng]

-1. Labels should make it unambiguous which control flow statement you are
breaking out of. This proposal makes code more fragile: what if the "break
outer for" code is later nested within another for loop, or the outer for
loop is changed to a while loop? The meaning of the code has silently
changed. More generally, the Swift design guidelines explicitly discourage
trying to increase code brevity at the expense of clarity.

Austin

On Wed, Dec 9, 2015 at 3:23 PM, Amir Michail via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Dec 9, 2015, at 5:56 PM, Chris Lattner <clattner at apple.com> wrote:
>
>
> On Dec 9, 2015, at 1:26 PM, Amir Michail via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> With such constructs, you could avoid using labels most of the time.
>
>
> Quick comment: this doesn’t eliminate the need for labels (since they
> provide the ability to break out of e.g. doubly nested for loops), but it
> does add complexity to the language.  As such, it doesn’t seem like a clear
> win to me.
>
>
> One of my examples has “break outer for”. I think it might be possible to
> eliminate labels completely with a reasonable looking syntax.
>
>
> -Chris
>
>
> For example:
>
> for … {
> if … {
>   guard … else { break if }
>   ...
> }
> }
>
> for … {
> for … {
>   if … {
>     break outer for
>   }
> }
> }
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151209/20661ea5/attachment.html>