[swift-evolution] for-else syntax

[Alejandro Martinez]

-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 at 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 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
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Alejandro Martinez
http://alejandromp.com