> 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
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 <https://mail.python.org/pipermail/python-ideas/2009-October/006155.html>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
