<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 Dec 27, 2015, at 2:30 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="">I realize this is on the commonly rejected list, but I really find closure syntax to be one of the more unintuitive and unreadable parts of Swift so I'd like to try to influence it. "Clarity at the point of use" is one of the main stated goals of Swift, and the fact that <a href="http://goshdarnclosuresyntax.com/" class="">http://goshdarnclosuresyntax.com/</a> exists shows me that it's not just me that thinks the syntax could be improved. I believe that we can get very close to the same results in line length and expressiveness while making the language much more readable and clear.</div></div></blockquote><div><br class=""></div><div>FWIW, I think that web site exists as a continuation of the “blocks” web site.</div><div><br class=""></div><div>From your description, it sounds like you might want to try out nested functions. They have a more explicit syntax, and still provide the same “closure” power as closure expressions.</div><div><br class=""></div><div>-Chris</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Let's start with a few use cases to illustrate what I mean when I say that reading closure syntax is difficult. Most programmers scan left to right, so when I see this property declaration:</div><div class=""><br class=""></div><div class="">var thing: Int</div><div class=""><br class=""></div><div class="">My brain reads that as a property of a class that's an integer. Unless of course there's this:</div><div class=""><br class=""></div><div class="">var thing: Int -> Int</div><div class=""><br class=""></div><div class="">Boom, context switch. If you've read "Int" than any following syntax should be a modifier on Int. For example, Int? works great, because in my head it's still an Integer, just an optional form of that Integer. While it's not a huge change in that example, lets take a more complicated one:</div><div class=""><br class=""></div><div class="">var thing: (String -> (), Int, (Int, Int) -> Bool)) -> Bool</div><div class=""><br class=""></div><div class="">Reading that left to right requires all sorts of context switching in my brain. I can't even tell at first glance how many params are in that closure. Reading left to right, you read "First parameter, string, no wait, closure that takes string, and returns void. Second param, Int. Third param, tuple with two ints, no wait, closure that takes two ints and returns bool." I just doesn't have much clarity.</div><div class=""><br class=""></div><div class="">I believe it's already been proposed, but I don't feel there's a strong enough difference between a closure and a function to justify a different syntax. Let's replace my examples above with anonymous function syntax.</div><div class=""><br class=""></div><div class="">var thing: func (Int) -> Int</div><div class=""><br class=""></div><div class="">Reading left to right, it reads the way that I think about it "A function that takes an integer and returns an integer."</div><div class=""><br class=""></div><div class="">var thing: func(func (String), Int, func (Int, Int) -> Bool) -> Bool</div><div class=""><br class=""></div><div class="">Again, reading left to right this is a win. "Thing is an anonymous function. First param, a function that takes a string. Second param, Int. Third param, a function that takes two ints and returns bool." It reads like people think.</div><div class=""><br class=""></div><div class="">Another strength is it lets us both use the same syntax for closures as we would expect, while letting us use just about all of the same shorthands we gain with closures. We could call normally like this, with the return type implied when async is called:</div><div class=""><br class=""></div><div class="">func async(callback: func (Bool) -> Bool))</div><div class=""><br class=""></div><div class="">async(func (successful: Bool) {</div><div class=""> return !successful<br class=""></div><div class="">});</div><div class=""><br class=""></div><div class="">We could still permit this:</div><div class=""><br class=""></div><div class="">func async(callback: func ())</div><div class=""><br class=""></div><div class="">async {</div><div class=""> //Do callback stuff here</div><div class="">}</div><div class=""><br class=""><div class="">We could still permit this:</div><div class=""><br class=""></div><div class="">func sort(sortfunc: func(Int, Int) -> Bool)</div><div class=""><br class=""></div><div class="">sort {</div><div class=""> $0 > $1</div><div class="">}</div><div class=""><br class=""></div></div><div class="">We could add this:</div><div class=""><br class=""></div><div class="">let greaterThan: func (number: Int) -> Bool = {</div><div class=""> number > 5</div><div class="">}</div><div class=""><br class=""></div><div class="">There would also be a few small wins, such as no longer needing "()" to represent a void return, since any function without a return type would imply a void return.</div><div class=""><br class=""></div><div class="">I understand that a big part of the decision for current closure syntax is to help the compiler, but I believe by doing so you're going against the main principles you laid out in your api design guidelines (<a href="https://swift.org/documentation/api-design-guidelines.html" class="">https://swift.org/documentation/api-design-guidelines.html</a>). Current closure syntax is not clear and breaks precedent of all other function like declarations having the parameters listed outside of the curly braces.</div><div class=""><br class=""></div><div class="">Thanks for listening, and great job on Swift so far.</div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=RC5Cq0zAxCHc1sM9Uy3-2BojrrUAw-2F96zH69NULNHPvCv3bvM5ehXrBN82Adgocc41YRvZisAPOwLlcicwXU6S0alCbgnP6U-2F1RUKS36NTN1Lp5snXhGYpUrwjQKJtjm8wbU6mwxDMN6koR0CswpZc4LcGRd29wKS0kIPeyK1jeDWhIj-2BAip92PG0q1UJEbwVOROswmShbN9oCsYiOh2sbH20kJNga2qRhhyvfyfvAuN4-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>