<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=""><div class="">I think => may be confusing in many of shown cases. Its a cause/efect symbol and can be also and operator.</div><div class=""><br class=""></div><div class="">I put again the idea of with for the newcomers:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Courier New" class="">with ( <b class="">parameters</b> ) -> <b class="">return_type</b> {</font></div><div class=""><font face="Courier New" class=""> <b class="">statements</b></font></div><div class=""><font face="Courier New" class="">}</font></div></div><div class=""><br class=""></div><div class=""><div class=""><div class=""><br class=""></div><div class=""><span style="font-family: 'Courier New';" class="">sorted = names.sort(</span><span style="font-family: 'Courier New';" class=""> </span><b class="" style="font-family: 'Courier New';">with</b><span style="font-family: 'Courier New';" class="">(s1, s2){ s1 > s2 } )</span></div><div class=""><div class=""><font face="Courier New" class=""><br class=""></font></div><div class=""><span style="font-family: 'Courier New';" class="">sorted</span><span style="font-family: 'Courier New';" class=""> = names.sort(</span><span style="font-family: 'Courier New';" class=""> </span><b class="" style="font-family: 'Courier New';">with</b><span style="font-family: 'Courier New';" class="">{ $0 > $1 } )</span></div><div class=""><div class=""><br class=""></div></div></div></div><div class=""><font face="Courier New" class=""><br class=""></font></div><div class=""><div class=""><font face="Courier New" class="">sorted = names.sort() <b class="">with</b> { $0 > $1 } </font></div><div class=""><font face="Courier New" class=""><br class=""></font></div></div><div class=""><font face="Courier New" class="">reversed = names.sort <b class="">with</b><span class="">(s1,s2)</span>{</font></div><div class=""><font face="Courier New" class=""><br class=""></font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>//bla bla code</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>return resultVar </font></div><div class=""><font face="Courier New" class="">}</font></div><div class=""><font face="Courier New" class=""> </font></div><div class=""><div class=""><font face="Courier New" class="">reversed = names.sort <b class="">with</b> { $0 > $1 } </font></div><div class=""><font face="Courier New" class=""><br class=""></font></div><div class=""><font face="Courier New" class=""><br class=""></font></div><div class="">But thinking about it, what we are really always doing with clousures is solving a quicky tiny delegation pattern. Maybe we could name it what it is. Too long word, but just to brainstorm.</div><div class=""><br class=""></div><div class=""><div class=""><div class=""><font face="Courier New" class="">delegating ( <b class="">parameters</b> ) -> <b class="">return_type</b> {</font></div><div class=""><font face="Courier New" class=""> <b class="">statements</b></font></div><div class=""><font face="Courier New" class="">}</font></div></div><div class=""><br class=""></div><div class=""><div class=""><div class=""><br class=""></div><div class=""><span style="font-family: 'Courier New';" class="">sorted = names.sort(</span><span style="font-family: 'Courier New';" class=""> </span><span style="font-family: 'Courier New';" class=""><b class="">delegating</b></span><span style="font-family: 'Courier New';" class="">(s1, s2){ s1 > s2 } )</span></div><div class=""><div class=""><font face="Courier New" class=""><br class=""></font></div><div class=""><span style="font-family: 'Courier New';" class="">sorted</span><span style="font-family: 'Courier New';" class=""> = names.sort(</span><span style="font-family: 'Courier New';" class=""> </span><span style="font-family: 'Courier New';" class=""><b class="">delegating</b></span><span style="font-family: 'Courier New';" class="">{ $0 > $1 } )</span></div><div class=""><div class=""><br class=""></div></div></div></div><div class=""><font face="Courier New" class=""><br class=""></font></div><div class=""><div class=""><font face="Courier New" class="">sorted = names.sort() <b class="">delegating</b>{ $0 > $1 } </font></div><div class=""><font face="Courier New" class=""><br class=""></font></div></div><div class=""><font face="Courier New" class="">reversed = names.sort <span class=""><b class="">delegating</b>(s1,s2)</span>{</font></div><div class=""><font face="Courier New" class=""><br class=""></font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>//bla bla code</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>return resultVar </font></div><div class=""><font face="Courier New" class="">}</font></div><div class=""><font face="Courier New" class=""> </font></div><div class=""><div class=""><font face="Courier New" class="">reversed = names.sort <b class="">delegating</b>{ $0 > $1 }</font></div></div></div></div></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">:)</div><br class=""><div><blockquote type="cite" class=""><div class="">El 23 des 2015, a les 12:49, Pierre Monod-Broca via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> va escriure:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I like that the closure parameters are inside the closure, to me it makes as much sense as outside. They're the input, so as much in as out.<div class=""><br class=""></div><div class="">I have nothing against `in`, but I wouldn't be against a sensible replacement.</div><div class="">I like `=>`, but I'm concerned it might be confused with `->` by beginners in swift.</div><div class=""><br class=""></div><div class=""><div class="">
<div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">-- </div><div class="">Pierre</div></div>
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 23 déc. 2015 à 11:21, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">I have to admit I haven't read the entire thread, so maybe I missed discussion of this.<br class=""><br class="">I, too, don't like the `params in code` syntax. After a year and a half with Swift, I now remember it, but it still reads funny, and I see new developers struggle with it frequently. I've also used Ruby quite a bit, but I really don't like the `||` syntax there either.<br class=""><br class="">What I would do is pull the parameters/type signature out of the braces and put a symbol in front of them. For example:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let names = people.map => person { person.name }<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>database.saveRecord(record) => record, error {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>if let record = record {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>completionHandler(true)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>}<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>else {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>handleError(error!)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>}<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}<br class=""><br class="">`=>` is used here merely because it's been discussed upthread; I actually think it's a little too heavy for this role, but I don't have a great replacement immediately at hand.<br class=""><br class="">A no-parameters closure would not require a `=>`; a bare block would still do there. I suppose the capture list would still go before the parameters, but after the `=>`. Other closure features remain the same—you can still use the `$N` implicit parameters, and you can still use `->` to specify a return value, `()` to surround the parameters, `:` to specify exact types, etc.<br class=""><br class="">-- <br class="">Brent Royal-Gordon<br class="">Architechies<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=AdkfTiApI80cNEyortTzHW0kAjxqiRekfpEJArOEyyqdG00ewNOnzWjVsrMwaYQXgErsTUYqalJ2Ryue8MWVrFAV1uMUWe5qxQIQLM2bc3ONeyDhe3GYWTlp-2FJfJPh756Gmmnbf9OYVA18MLEERAuiVS8lby3aiq-2Bsp5eLH71NynuxGokLMq45LF4s5TvhYisWsc3v4VeMmSDIkNE9qZTa3xbqNdu-2Fu3mTuwT-2FqWJtY-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="">
</div>
_______________________________________________<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>