[swift-evolution] for-else syntax

[Derrick Ho]

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

>
> On Feb 6, 2017, at 11:06 AM, Jordan Rose via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Feb 6, 2017, at 02:50, Jeremy Pereira via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On 3 Feb 2017, at 18:00, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> on Fri Feb 03 2017, Dimitri Racordon <swift-evolution at 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
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170207/6dc7f65e/attachment.html>