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
