-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 <[email protected]> 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 > <[email protected]> wrote: >> >> >> On Feb 6, 2017, at 11:06 AM, Jordan Rose via swift-evolution >> <[email protected]> wrote: >> >> >> On Feb 6, 2017, at 02:50, Jeremy Pereira via swift-evolution >> <[email protected]> wrote: >> >> >> On 3 Feb 2017, at 18:00, Dave Abrahams via swift-evolution >> <[email protected]> wrote: >> >> >> on Fri Feb 03 2017, Dimitri Racordon <[email protected]> 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: >> https://mail.python.org/pipermail/python-ideas/2009-October/006155.html >> >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > -- Alejandro Martinez http://alejandromp.com _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
