Proposal: "break for", "break do", "break if", "break case", "break repeat", etc

With such constructs, you could avoid using labels most of the time.

For example:

for … {
  if … {
    guard … else { break if }
    ...
  }
}

for … {
  for … {
    if … {
      break outer for
    }
  }
}

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.

-Chris

···

On Dec 9, 2015, at 1:26 PM, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

For example:

for … {
if … {
   guard … else { break if }
   ...
}
}

for … {
for … {
   if … {
     break outer for
   }
}
}

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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.

···

On Dec 9, 2015, at 5:56 PM, Chris Lattner <clattner@apple.com> wrote:

On Dec 9, 2015, at 1:26 PM, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-Chris

For example:

for … {
if … {
  guard … else { break if }
  ...
}
}

for … {
for … {
  if … {
    break outer for
  }
}
}

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

I think "outer: for { ... { ... break outer } }" is significantly more
clear than a magical "break outer for" syntax that tries to describe in
English which loop to break out of.

Jacob Bandes-Storch

···

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

On Dec 9, 2015, at 5:56 PM, Chris Lattner <clattner@apple.com> wrote:

On Dec 9, 2015, at 1:26 PM, Amir Michail via swift-evolution < > swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

-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@swift.org> wrote:

On Dec 9, 2015, at 5:56 PM, Chris Lattner <clattner@apple.com> wrote:

On Dec 9, 2015, at 1:26 PM, Amir Michail via swift-evolution < > swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

How would you deal with in-between cases, where you don’t want to break all the way to the topmost loop?

This is a somewhat contrived example, but illustrates the point:

for … {
    mylabel: for … {
        for … {
            if (condition) { break mylabel }
        }
    }
}

How do you write this without labels?

— Alex

···

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

On Dec 9, 2015, at 5:56 PM, Chris Lattner <clattner@apple.com> wrote:

On Dec 9, 2015, at 1:26 PM, Amir Michail via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution