for-else syntax

Evolution Discussion
21

I don't have a anything to say about for-else, but just a comment on the
meta-point of how we evaluate designs: precedent set by other languages
affects learnability, and is one of the criteria we've always considered
when designing Swift.

HTH,

···

on Fri Feb 03 2017, Dimitri Racordon <swift-evolution@swift.org> wrote:

Talking of Python, Swift is not Python and the argument not to
implement a feature because its semantics conflict with the semantics
of a similar looking feature in another language is bogus.

--
-Dave

22

This doesn't work with break or continue and changes the meaning of return.

It would be nice for Swift to support Tcl-like exceptional return codes so
we can build control flow functions that work with break, continue, and
return properly.

http://www.tcl.tk/man/tcl/TclCmd/return.htm

···

On Fri, Feb 3, 2017 at 7:15 PM, Howard Lovatt via swift-users < swift-users@swift.org> wrote:

Why not add to the library:

extension Sequence {
    func forEach(_ eacher: (Iterator.Element) throws -> Void, elser: ()
throws -> Void) rethrows {

23

Maybe we can add a new parameter "otherwise" to the forEach method

[1,2,3,4].forEach({
// do something
}
, otherwise: {
// do something if it is an empty array
})

That could be a decent compromise; just tried a simple extension and the following seems to work quite nicely:

extension Sequence {
  func forEach(_ body: (Iterator.Element) throws -> Void, otherwise: () throws -> Void) rethrows -> Void {
    var it = self.makeIterator()
    if let first = it.next() {
      try body(first)
      while let current = it.next() { try body(current) }
    } else { try otherwise() }
  }
}

let names = ["foo", "bar", "baz"], empty:[String] =
names.forEach({ print($0) }, otherwise: { print("no names") })
empty.forEach({ print($0) }, otherwise: { print("no names") })

Of course it lacks the ability to use continue or break, so the question is; does it add enough utility to add, or is it better left to developers to extend themselves?

···

On 2 Feb 2017, at 13:44, Derrick Ho <wh1pch81n@gmail.com> wrote:

On Thu, Feb 2, 2017 at 6:31 AM Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'm of two minds on this feature; I kind of support the idea of the construct, especially because there are some behind the scenes optimisations it can do, and it can look neater.
However, I'm not at all keen on the re-use of else; if there were a better keyword I might suppose that, for example "empty" or something like that, but nothing I can think of feels quite right.

I mean, when it comes down to it the "best" way to write the loop is like:

var it = names.makeIterator()
if let first = it.next() {
  print(first)
  while let current = it.next() { print(current) }
} else { print("no names") }

However this is a horrible thing to do in your own code, especially if the loop body is larger than one line, but is just fine if it's done behind the scenes for you (complete with unwrapping of the iterators if their type is known).

Which is why I kind of like the idea of having the construct itself; otherwise, like others, I use the less "correct" option like so (for sequences):

var empty = true
for name in names { print(name); empty = false }
if empty { print("no names") }

At which point I simply hope that the compiler optimises away the assignment (since it only actually does something on the first pass).

So yeah, I can see a use for it, but I'd prefer a construct other than for/else to do it; at the very least a different keyword, as there's the possibility we could also have a while/else as well and it would need to be very clear, which I don't feel that for/else is.

On 2 Feb 2017, at 11:06, Jeremy Pereira via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 1 Feb 2017, at 18:29, Chris Davis via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

ah! I forgot about the break semantics, that’s definitely one for the con list.

I like Nicolas’ solution, clear to read.

On 1 Feb 2017, at 18:18, Nicolas Fezans <nicolas.fezans@gmail.com <mailto:nicolas.fezans@gmail.com>> wrote:

I tend to write this kind of treatment the other way around...

if names.isEmpty {
  // do whatever
} // on other cases I might have a few else-if to treat other cases that need special treament
else {
  for name in names {
    // do your thing
  }
}

This only works if you know the size of the sequence before you start iterating it. You can, for example, iterate a lazy sequence and calculating its size before iterating it defeats the object.Thus for { … } else { … } where the else block only executes if the for block was never executed does have some utility.

However, I am not in favour adding it. The same functionality can be achieved by counting the number of iterations and testing the count afterwards (or by using a boolean). It takes a couple of extra lines of code and an extra variable, but I think that is a Good Thing. It’s more explicit and (as the Python example shows) there could be hidden subtleties that confuse people if for … else … is badly designed. Also, in many cases, I would argue that treating the zero element sequence differently to the n > 0 element sequence is a code smell. About the only use-case I can think of off the top of my head is UI presentation e.g. “your search didn’t return any results” instead of a blank page.

Talking of Python, Swift is not Python and the argument not to implement a feature because its semantics conflict with the semantics of a similar looking feature in another language is bogus. I don’t see the Python for … else being different (and having looked it up to see what you all were talking about, my opinion is that the Python for … else is a disaster) as being a legitimate con to this cleaner and more logical idea in Swift.

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

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

24

It would be nice for Swift to support Tcl-like exceptional return codes so we can build control flow functions that work with break, continue, and return properly.

Wouldn't that collide in some way with the error handling mechanism already present in swift ?
Today, you can return a value, possibly optional to return nil if the method might not be able to find the requested value, or to compute it, or you can throw errors for invalid situations. You can then fine tune your errors, to denote an error case (hopefully with some details), a break case, ...

Uniform and coherent error handling is not easy to achieve, I fear that adding another way to report and handle them would not help in that regard.

Jerome

25

It is a functional style, so typically you use return for continue and
throws to accomplish break and return, e.g.:

    // Continue
    let a = [0, 1]
    a.forEach { _ in return } // for _ in a { continue }

    // Break and return
    enum LoopControls<T>: Error {
        case exitLoop // Break
        case returnValue(T) // Return
    }
    do {
        do {
            try a.forEach { _ in throw LoopControls<Void>.exitLoop } // for
_ in a { break }
        } catch LoopControls<Void>.exitLoop {
            // Process break if you need to
        }
        try a.forEach { _ in throw LoopControls<Double>.returnValue(42.0) }
// for _ in a { return 42.0 }
    } catch LoopControls<Double>.returnValue(let value) {
        return value
    }

···

On Sun, 5 Feb 2017 at 2:32 pm, Rob Mayoff via swift-users < swift-users@swift.org> wrote:

On Fri, Feb 3, 2017 at 7:15 PM, Howard Lovatt via swift-users < > swift-users@swift.org> wrote:

Why not add to the library:

extension Sequence {
    func forEach(_ eacher: (Iterator.Element) throws -> Void, elser: ()
throws -> Void) rethrows {

This doesn't work with break or continue and changes the meaning of return.

It would be nice for Swift to support Tcl-like exceptional return codes so
we can build control flow functions that work with break, continue, and
return properly.

return manual page - Tcl Built-In Commands
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

--
-- Howard.

26

Talking of Python, Swift is not Python and the argument not to
implement a feature because its semantics conflict with the semantics
of a similar looking feature in another language is bogus.

I don't have a anything to say about for-else, but just a comment on the
meta-point of how we evaluate designs: precedent set by other languages
affects learnability, and is one of the criteria we've always considered
when designing Swift.

Two things:

1. Somehow the quoting in your email has got messed up so it looks like a statement I made was made by somebody else who may or may not agree with the sentiment expressed.

2. You’ve never been shy of going against precedent if you consider it to be a *bad* precedent. Otherwise Swift would still have C style for loops and pre/post increment/decrement operators. That is as it should be. The Python for … else statement is a mess. My brief survey of the Internet suggests it is confusing even to some Python programmers. It should not be allowed to prevent the Swift team from implementing similarly named but better designed features if there are other good reasons for doing so.

···

On 3 Feb 2017, at 18:00, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Fri Feb 03 2017, Dimitri Racordon <swift-evolution@swift.org> wrote:

HTH,

--
-Dave

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

27

I would prefer `ifNone:` instead of `otherwise` as it makes the semantics clearer IMHO.

-Thorsten

···

Am 03.02.2017 um 12:50 schrieb Haravikk via swift-evolution <swift-evolution@swift.org>:

On 2 Feb 2017, at 13:44, Derrick Ho <wh1pch81n@gmail.com> wrote:

Maybe we can add a new parameter "otherwise" to the forEach method

[1,2,3,4].forEach({
// do something
}
, otherwise: {
// do something if it is an empty array
})

That could be a decent compromise; just tried a simple extension and the following seems to work quite nicely:

extension Sequence {
  func forEach(_ body: (Iterator.Element) throws -> Void, otherwise: () throws -> Void) rethrows -> Void {
    var it = self.makeIterator()
    if let first = it.next() {
      try body(first)
      while let current = it.next() { try body(current) }
    } else { try otherwise() }
  }
}

let names = ["foo", "bar", "baz"], empty:[String] =
names.forEach({ print($0) }, otherwise: { print("no names") })
empty.forEach({ print($0) }, otherwise: { print("no names") })

Of course it lacks the ability to use continue or break, so the question is; does it add enough utility to add, or is it better left to developers to extend themselves?

On Thu, Feb 2, 2017 at 6:31 AM Haravikk via swift-evolution <swift-evolution@swift.org> wrote:
I'm of two minds on this feature; I kind of support the idea of the construct, especially because there are some behind the scenes optimisations it can do, and it can look neater.
However, I'm not at all keen on the re-use of else; if there were a better keyword I might suppose that, for example "empty" or something like that, but nothing I can think of feels quite right.

I mean, when it comes down to it the "best" way to write the loop is like:

var it = names.makeIterator()
if let first = it.next() {
  print(first)
  while let current = it.next() { print(current) }
} else { print("no names") }

However this is a horrible thing to do in your own code, especially if the loop body is larger than one line, but is just fine if it's done behind the scenes for you (complete with unwrapping of the iterators if their type is known).

Which is why I kind of like the idea of having the construct itself; otherwise, like others, I use the less "correct" option like so (for sequences):

var empty = true
for name in names { print(name); empty = false }
if empty { print("no names") }

At which point I simply hope that the compiler optimises away the assignment (since it only actually does something on the first pass).

So yeah, I can see a use for it, but I'd prefer a construct other than for/else to do it; at the very least a different keyword, as there's the possibility we could also have a while/else as well and it would need to be very clear, which I don't feel that for/else is.

On 2 Feb 2017, at 11:06, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:

On 1 Feb 2017, at 18:29, Chris Davis via swift-evolution <swift-evolution@swift.org> wrote:

ah! I forgot about the break semantics, that’s definitely one for the con list.

I like Nicolas’ solution, clear to read.

On 1 Feb 2017, at 18:18, Nicolas Fezans <nicolas.fezans@gmail.com> wrote:

I tend to write this kind of treatment the other way around...

if names.isEmpty {
  // do whatever
} // on other cases I might have a few else-if to treat other cases that need special treament
else {
  for name in names {
    // do your thing
  }
}

This only works if you know the size of the sequence before you start iterating it. You can, for example, iterate a lazy sequence and calculating its size before iterating it defeats the object.Thus for { … } else { … } where the else block only executes if the for block was never executed does have some utility.

However, I am not in favour adding it. The same functionality can be achieved by counting the number of iterations and testing the count afterwards (or by using a boolean). It takes a couple of extra lines of code and an extra variable, but I think that is a Good Thing. It’s more explicit and (as the Python example shows) there could be hidden subtleties that confuse people if for … else … is badly designed. Also, in many cases, I would argue that treating the zero element sequence differently to the n > 0 element sequence is a code smell. About the only use-case I can think of off the top of my head is UI presentation e.g. “your search didn’t return any results” instead of a blank page.

Talking of Python, Swift is not Python and the argument not to implement a feature because its semantics conflict with the semantics of a similar looking feature in another language is bogus. I don’t see the Python for … else being different (and having looked it up to see what you all were talking about, my opinion is that the Python for … else is a disaster) as being a legitimate con to this cleaner and more logical idea in Swift.

_______________________________________________
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

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

28

This is not at odds with what you’re saying, but I wanted to add that there’s a difference between removing syntax and having conflicting syntax. That is, not having a for-else loop is fine, but having a for-else loop that behaves differently than Python’s would require a pretty strong reason. As far as I know there’s only one place where we deliberately chose to conflict with another language’s precedent, and that’s '…' being an inclusive range (where it is the exclusive range operator in Ruby), and that discussion led to us picking '..<‘ instead of ‘..’ for the other operator.

Jordan

···

On Feb 6, 2017, at 02:50, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:

On 3 Feb 2017, at 18:00, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Fri Feb 03 2017, Dimitri Racordon <swift-evolution@swift.org> wrote:

Talking of Python, Swift is not Python and the argument not to
implement a feature because its semantics conflict with the semantics
of a similar looking feature in another language is bogus.

I don't have a anything to say about for-else, but just a comment on the
meta-point of how we evaluate designs: precedent set by other languages
affects learnability, and is one of the criteria we've always considered
when designing Swift.

Two things:

1. Somehow the quoting in your email has got messed up so it looks like a statement I made was made by somebody else who may or may not agree with the sentiment expressed.

2. You’ve never been shy of going against precedent if you consider it to be a *bad* precedent. Otherwise Swift would still have C style for loops and pre/post increment/decrement operators. That is as it should be. The Python for … else statement is a mess. My brief survey of the Internet suggests it is confusing even to some Python programmers. It should not be allowed to prevent the Swift team from implementing similarly named but better designed features if there are other good reasons for doing so.

29

And despite disliking the updated .../..< operators at first, I find it has increased
inspectability and clarity at the point of use. Good call in my opinion.
Similar behaviors and outcomes should adopt conventional syntax unless
an updated syntax offers measurable benefits.

-- E

Mildly interesting reference:
https://mail.python.org/pipermail/python-ideas/2009-October/006155.html

···

On Feb 6, 2017, at 11:06 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 6, 2017, at 02:50, Jeremy Pereira via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 3 Feb 2017, at 18:00, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

on Fri Feb 03 2017, Dimitri Racordon <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Talking of Python, Swift is not Python and the argument not to
implement a feature because its semantics conflict with the semantics
of a similar looking feature in another language is bogus.

I don't have a anything to say about for-else, but just a comment on the
meta-point of how we evaluate designs: precedent set by other languages
affects learnability, and is one of the criteria we've always considered
when designing Swift.

Two things:

1. Somehow the quoting in your email has got messed up so it looks like a statement I made was made by somebody else who may or may not agree with the sentiment expressed.

2. You’ve never been shy of going against precedent if you consider it to be a *bad* precedent. Otherwise Swift would still have C style for loops and pre/post increment/decrement operators. That is as it should be. The Python for … else statement is a mess. My brief survey of the Internet suggests it is confusing even to some Python programmers. It should not be allowed to prevent the Swift team from implementing similarly named but better designed features if there are other good reasons for doing so.

This is not at odds with what you’re saying, but I wanted to add that there’s a difference between removing syntax and having conflicting syntax. That is, not having a for-else loop is fine, but having a for-else loop that behaves differently than Python’s would require a pretty strong reason. As far as I know there’s only one place where we deliberately chose to conflict with another language’s precedent, and that’s '…' being an inclusive range (where it is the exclusive range operator in Ruby), and that discussion led to us picking '..<‘ instead of ‘..’ for the other operator.

Jordan

30

I'm not really seeing the advantage of `for item in collection else` being discussed or a compelling use case that motivates a language change.

You can check the empty case first for empty collections:

if collection.isEmpty {
    ...
} else for item in collection {
    ...
}

If you're filtering while iterating, you can use an access counter, for what is surely an uncommon test, or better yet, filter first and use the leading isEmpty test:

var access = 0
for item in collection where condition {
    access += 1
}
if access == 0 {
}

It seems to me that the only reason the language should change would be to handle abnormal loop processing, such as a break, but then why not throw an error and embed the for-loop in a do-catch? And honestly, I don't really think I'd ever use this or could think of a scenario where I'd need this.

-- E

···

On Feb 3, 2017, at 10:01 AM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

I would prefer `ifNone:` instead of `otherwise` as it makes the semantics clearer IMHO.

-Thorsten

Am 03.02.2017 um 12:50 schrieb Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

On 2 Feb 2017, at 13:44, Derrick Ho <wh1pch81n@gmail.com <mailto:wh1pch81n@gmail.com>> wrote:

Maybe we can add a new parameter "otherwise" to the forEach method

[1,2,3,4].forEach({
// do something
}
, otherwise: {
// do something if it is an empty array
})

That could be a decent compromise; just tried a simple extension and the following seems to work quite nicely:

extension Sequence {
  func forEach(_ body: (Iterator.Element) throws -> Void, otherwise: () throws -> Void) rethrows -> Void {
    var it = self.makeIterator()
    if let first = it.next() {
      try body(first)
      while let current = it.next() { try body(current) }
    } else { try otherwise() }
  }
}

let names = ["foo", "bar", "baz"], empty:[String] =
names.forEach({ print($0) }, otherwise: { print("no names") })
empty.forEach({ print($0) }, otherwise: { print("no names") })

Of course it lacks the ability to use continue or break, so the question is; does it add enough utility to add, or is it better left to developers to extend themselves?

On Thu, Feb 2, 2017 at 6:31 AM Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'm of two minds on this feature; I kind of support the idea of the construct, especially because there are some behind the scenes optimisations it can do, and it can look neater.
However, I'm not at all keen on the re-use of else; if there were a better keyword I might suppose that, for example "empty" or something like that, but nothing I can think of feels quite right.

I mean, when it comes down to it the "best" way to write the loop is like:

var it = names.makeIterator()
if let first = it.next() {
  print(first)
  while let current = it.next() { print(current) }
} else { print("no names") }

However this is a horrible thing to do in your own code, especially if the loop body is larger than one line, but is just fine if it's done behind the scenes for you (complete with unwrapping of the iterators if their type is known).

Which is why I kind of like the idea of having the construct itself; otherwise, like others, I use the less "correct" option like so (for sequences):

var empty = true
for name in names { print(name); empty = false }
if empty { print("no names") }

At which point I simply hope that the compiler optimises away the assignment (since it only actually does something on the first pass).

So yeah, I can see a use for it, but I'd prefer a construct other than for/else to do it; at the very least a different keyword, as there's the possibility we could also have a while/else as well and it would need to be very clear, which I don't feel that for/else is.

On 2 Feb 2017, at 11:06, Jeremy Pereira via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 1 Feb 2017, at 18:29, Chris Davis via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

ah! I forgot about the break semantics, that’s definitely one for the con list.

I like Nicolas’ solution, clear to read.

On 1 Feb 2017, at 18:18, Nicolas Fezans <nicolas.fezans@gmail.com <mailto:nicolas.fezans@gmail.com>> wrote:

I tend to write this kind of treatment the other way around...

if names.isEmpty {
  // do whatever
} // on other cases I might have a few else-if to treat other cases that need special treament
else {
  for name in names {
    // do your thing
  }
}

This only works if you know the size of the sequence before you start iterating it. You can, for example, iterate a lazy sequence and calculating its size before iterating it defeats the object.Thus for { … } else { … } where the else block only executes if the for block was never executed does have some utility.

However, I am not in favour adding it. The same functionality can be achieved by counting the number of iterations and testing the count afterwards (or by using a boolean). It takes a couple of extra lines of code and an extra variable, but I think that is a Good Thing. It’s more explicit and (as the Python example shows) there could be hidden subtleties that confuse people if for … else … is badly designed. Also, in many cases, I would argue that treating the zero element sequence differently to the n > 0 element sequence is a code smell. About the only use-case I can think of off the top of my head is UI presentation e.g. “your search didn’t return any results” instead of a blank page.

Talking of Python, Swift is not Python and the argument not to implement a feature because its semantics conflict with the semantics of a similar looking feature in another language is bogus. I don’t see the Python for … else being different (and having looked it up to see what you all were talking about, my opinion is that the Python for … else is a disaster) as being a legitimate con to this cleaner and more logical idea in Swift.

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

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

31

I don't like the idea of for-else since it doesn't really add much value.
It hardly saves you any typing.

-1

···

On Mon, Feb 6, 2017 at 6:26 PM Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:

On Feb 6, 2017, at 11:06 AM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote:

On Feb 6, 2017, at 02:50, Jeremy Pereira via swift-evolution < > swift-evolution@swift.org> wrote:

On 3 Feb 2017, at 18:00, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:

on Fri Feb 03 2017, Dimitri Racordon <swift-evolution@swift.org> wrote:

Talking of Python, Swift is not Python and the argument not to
implement a feature because its semantics conflict with the semantics
of a similar looking feature in another language is bogus.

I don't have a anything to say about for-else, but just a comment on the
meta-point of how we evaluate designs: precedent set by other languages
affects learnability, and is one of the criteria we've always considered
when designing Swift.

Two things:

1. Somehow the quoting in your email has got messed up so it looks like a
statement I made was made by somebody else who may or may not agree with
the sentiment expressed.

2. You’ve never been shy of going against precedent if you consider it to
be a *bad* precedent. Otherwise Swift would still have C style for loops
and pre/post increment/decrement operators. That is as it should be. The
Python for … else statement is a mess. My brief survey of the Internet
suggests it is confusing even to some Python programmers. It should not be
allowed to prevent the Swift team from implementing similarly named but
better designed features if there are other good reasons for doing so.

This is not at odds with what you’re saying, but I wanted to add that
there’s a difference between *removing* syntax and having *conflicting* syntax.
That is, not having a for-else loop is fine, but having a for-else loop
that behaves differently than Python’s would require a pretty strong
reason. As far as I know there’s only one place where we deliberately chose
to conflict with another language’s precedent, and that’s '…' being an
inclusive range (where it is the exclusive range operator in Ruby), and
that discussion led to us picking '..<‘ instead of ‘..’ for the other
operator.

Jordan

And despite disliking the updated .../..< operators at first, I find it
has increased
inspectability and clarity at the point of use. Good call in my opinion.
Similar behaviors and outcomes should adopt conventional syntax unless
an updated syntax offers measurable benefits.

-- E

Mildly interesting reference:
[Python-ideas] Summary of for...else threads

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

32

-1 for me.
I don't see a good enough reasons to change the language and add
another control-flow variant. I would much rather see a language
improvement that somehow allowed to implement it as a lib supporting
break/continue. Something like what Haravikk suggested.

···

On Tue, Feb 7, 2017 at 12:26 AM, Derrick Ho via swift-evolution <swift-evolution@swift.org> wrote:

I don't like the idea of for-else since it doesn't really add much value. It
hardly saves you any typing.

-1
On Mon, Feb 6, 2017 at 6:26 PM Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote:

On Feb 6, 2017, at 11:06 AM, Jordan Rose via swift-evolution >> <swift-evolution@swift.org> wrote:

On Feb 6, 2017, at 02:50, Jeremy Pereira via swift-evolution >> <swift-evolution@swift.org> wrote:

On 3 Feb 2017, at 18:00, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote:

on Fri Feb 03 2017, Dimitri Racordon <swift-evolution@swift.org> wrote:

Talking of Python, Swift is not Python and the argument not to
implement a feature because its semantics conflict with the semantics
of a similar looking feature in another language is bogus.

I don't have a anything to say about for-else, but just a comment on the
meta-point of how we evaluate designs: precedent set by other languages
affects learnability, and is one of the criteria we've always considered
when designing Swift.

Two things:

1. Somehow the quoting in your email has got messed up so it looks like a
statement I made was made by somebody else who may or may not agree with the
sentiment expressed.

2. You’ve never been shy of going against precedent if you consider it to
be a *bad* precedent. Otherwise Swift would still have C style for loops and
pre/post increment/decrement operators. That is as it should be. The Python
for … else statement is a mess. My brief survey of the Internet suggests it
is confusing even to some Python programmers. It should not be allowed to
prevent the Swift team from implementing similarly named but better designed
features if there are other good reasons for doing so.

This is not at odds with what you’re saying, but I wanted to add that
there’s a difference between removing syntax and having conflicting syntax.
That is, not having a for-else loop is fine, but having a for-else loop that
behaves differently than Python’s would require a pretty strong reason. As
far as I know there’s only one place where we deliberately chose to conflict
with another language’s precedent, and that’s '…' being an inclusive range
(where it is the exclusive range operator in Ruby), and that discussion led
to us picking '..<‘ instead of ‘..’ for the other operator.

Jordan

And despite disliking the updated .../..< operators at first, I find it
has increased
inspectability and clarity at the point of use. Good call in my opinion.
Similar behaviors and outcomes should adopt conventional syntax unless
an updated syntax offers measurable benefits.

-- E

Mildly interesting reference:
[Python-ideas] Summary of for...else threads

_______________________________________________
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

--
Alejandro Martinez