<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 Jun 27, 2016, at 7:05 AM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:</div><div class=""><div class=""><blockquote type="cite" class="">for i in map { ... } { // will not compile<br class=""> ... <br class="">}<br class=""></blockquote><br class="">I don't think Swift wants to buy into the idea that using map without<br class="">trailing closures is a bad habit. We strongly believe in trailing</div></div></blockquote><blockquote type="cite" class=""><div class=""><div class="">closure syntax.</div></div></blockquote><div><br class=""></div><div>I strongly believe that trailing closure syntax isn't always the right thing. For example, </div><div>many APIs, specifically those sourced from Cocoa, shouldn't use trailing closures for </div><div>"completion", "on error" handlers, etc.</div><div><br class=""></div><div><font face="Menlo" class="">// Should use argument label. Clear, easy to distinguish</font></div><div><span style="font-family: Menlo;" class="">UIView.animate(</span></div><div><div><font face="Menlo" class=""> withDuration: 0.5,</font></div><div><font face="Menlo" class=""> delay: 0.0,</font></div><div><font face="Menlo" class=""> options: [.curveEaseOut],</font></div><div><font face="Menlo" class=""> animations: {</font></div><div><font face="Menlo" class=""> </font></div><div><font face="Menlo" class=""> //...</font></div><div><font face="Menlo" class=""> </font></div><div><font face="Menlo" class=""> },</font></div><div><font face="Menlo" class=""> completion: {</font></div><div><font face="Menlo" class=""> </font></div><div><font face="Menlo" class=""> _ in print("done animating")</font></div><div><font face="Menlo" class=""><br class=""></font></div><div><font face="Menlo" class=""> }</font></div><div><font face="Menlo" class="">)</font></div><div class=""><br class=""></div></div><div><div><font face="Menlo" class="">// Shouldn't use trailing closure syntax. The call look like </font></div><div><font face="Menlo" class="">// it's "running" the completion block. </font></div><div><font face="Menlo" class="">//</font></div><div><div><font face="Menlo" class="">UIView.animate(</font></div><div><font face="Menlo" class=""> withDuration: 0.5,</font></div><div><font face="Menlo" class=""> delay: 0.0,</font></div><div><font face="Menlo" class=""> options: [.curveEaseOut],</font></div><div><font face="Menlo" class=""> animations: {</font></div><div><font face="Menlo" class=""> </font></div><div><font face="Menlo" class=""> // ...</font></div><div><font face="Menlo" class=""> </font></div><div><font face="Menlo" class="">}) {</font></div><div><font face="Menlo" class=""> </font></div><div><font face="Menlo" class=""> _ in print("done animating")</font></div><div><font face="Menlo" class=""> </font></div><div><font face="Menlo" class="">}</font></div><div><font face="Menlo" class=""><br class=""></font></div></div><div>Compare with:</div><div><br class=""></div><div><font face="Menlo" class="">// Should. Elegant, simple.</font></div><div><div><span style="font-family: Menlo;" class="">DispatchQueue.main.after(when: .now() + 1.0) {</span></div><div><font face="Menlo" class=""><br class=""></font></div><div><font face="Menlo" class=""> print("complete")</font></div><div><font face="Menlo" class=""> PlaygroundPage.finishExecution(PlaygroundPage.current)</font></div><div><font face="Menlo" class=""><br class=""></font></div><div><font face="Menlo" class="">}</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class="">// Slightly less good</font></div><div class=""><span style="font-family: Menlo;" class="">DispatchQueue.main.after(when: .now() + 1.0, execute: {</span></div><div class=""><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class=""> print("complete")</font></div><div class=""><font face="Menlo" class=""> PlaygroundPage.finishExecution(PlaygroundPage.current)</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class="">})</font></div></div></div></div><div><br class=""></div><div><blockquote type="cite" class="">Why not make the argument that it's a bad habit to call map without</blockquote></div><blockquote type="cite" class=""><div class=""><div class="">*surrounding* parentheses?<br class=""></div></div></blockquote><div><br class=""></div><div>It's a fair question and as I have readily admitted, a highly stylized personal choice.</div><div>Using my style is a choice that has measurable benefits and limited impact. It fixes a real </div><div>(not theoretical) problem, is never harmful to code and when adhered to consistently</div><div>clarifies intent at the point of use, especially when expanded to functional calls that</div><div>aren't pre-built into the language -- so readers may not know at a glance what they're </div><div>looking at as they would with `map`, `flatMap`, `filter`, and whatever sort is being called</div><div>this week.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">I disagree about readability. One set of surrounding parentheses is<br class="">clearer<br class=""><br class=""> for var i in (x.flatMap{ Int($0) }.filter{ $0 < 10 }) {<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div>chacun à son goût. see above.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Further, I am concerned about pervasive inefficiency when people try to<br class="">pack this kind of chaining into a for loop with as few characters as<br class="">possible. Generally speaking, it would be better to do it lazily.<br class=""></div></div></blockquote><div><br class=""></div><div>Yeah, kicking myself over that. Can't Swift remind me to add `lazy` </div><div>by emitting a warning or something? I keep assuming certain things are</div><div>naturally lazy and then have to go back and de-eagerize.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">Enhanced readability from explicit coding intent. Trailing closures <br class="">*look* like a scope created by a native construct. Those enclosed in <br class="">parens *look* like arguments.<br class=""></blockquote><br class="">I understand what you're saying, but I think it's unnecessarily fussy<br class="">;-)<br class=""><br class="">two-can-play-at-that-game-ly y'rs,<br class=""></div></div></blockquote><div><br class=""></div></div>A hit, a very palpable hit.<div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div></body></html>