<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 Jan 1, 2016, at 4:21 PM, Ethan Diamond 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 dir="ltr" class="">FWIW I don't think the backlash to the use of ^ with Obj-C blocks was because of the carat itself, but because of the inconsistency of the syntax in different contexts. Sometimes the return type was after the ^, sometimes before. Sometimes you had to use (^). Sometimes the carat had the name of the block with it ^functionName. None of it fit in with the [object methodName] syntax of the language itself. </div></div></blockquote><br class=""></div><div>I’ll drop in a straight-up objection to the carat. The infix arrow syntax is perfectly clear, and in mathematical contexts has proved its readability since long before there were programming languages. Contra the proposal, there’s nothing wrong with this:</div><div><br class=""></div><div><div style="font-family: HelveticaNeue;" class=""><span style="font-family: monospace, monospace; font-size: 12.8px; white-space: pre-wrap;" class=""> func makeIncrementer(forIncrement amount: Int) -> () -> Int</span></div></div><div><br class=""></div><div>The carat, on the other hand, is noise. Only habituation to Obj-C blocks makes it seem like anything else.</div><div><br class=""></div><div>I _do_ agree that the { foo, bar in … } syntax is clumsy, both graphically and grammatically. Definitely not my favorite part of Swift. I don’t find the carat a compelling fix, however.</div><div><br class=""></div><div>Cheers,</div><div><br class=""></div><div>Paul</div><div><br class=""></div></body></html>