<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 6, 2017, at 02:50, Jeremy Pereira via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On 3 Feb 2017, at 18:00, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class="">on Fri Feb 03 2017, Dimitri Racordon <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Talking of Python, Swift is not Python and the argument not to<br class="">implement a feature because its semantics conflict with the semantics<br class="">of a similar looking feature in another language is bogus. <br class=""></blockquote><br class="">I don't have a anything to say about for-else, but just a comment on the<br class="">meta-point of how we evaluate designs: precedent set by other languages<br class="">affects learnability, and is one of the criteria we've always considered<br class="">when designing Swift.<br class=""><br class=""></blockquote><br class="">Two things:<br class=""><br class="">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.<br class=""><br class="">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.</div></div></blockquote><br class=""></div><div>This is not at odds with what you’re saying, but I wanted to add that there’s a difference between <i class="">removing</i> syntax and having <i class="">conflicting</i> 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.</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>