<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="">Does “in” really make sense semantically though? It seems to have confused almost everywhere, and as we’ve discussed, it’s not “delimited enough”.<div class=""><br class=""></div><div class="">My recent personal proposal was the syntax:</div><div class=""><br class=""></div><div class="">func x, y, z { … }</div><div class=""><br class=""></div><div class="">– for the reasons/advantages discussed in my post stating the grammar (and previous one).</div><div class=""><br class=""></div><div class="">If this can’t be effected, then I would compromise for the syntax that just replaces `in` with `>=` in the current syntax.</div><div class=""><br class=""></div><div class="">I also like the proposal of changing `->` to `:` in function type specifiers, for consistency. This also frees up another operator.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 23 Dec 2015, at 04:02, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</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=""><div class="">Hi, Alexander. For your most recent version, what does the syntax look like when there are explicit types? As far as I can tell the only change is substituting "in" for "=>", which means taking an existing keyword (from 'for' loops) and replacing it with what's currently a valid operator.</div><div class=""><br class=""></div><div class="">We definitely thought a lot about closure syntax; what we ended up with</div><div class="">(a) is concise,</div><div class="">(b) has some precedent, structurally (Ruby, Smalltalk),</div><div class="">(c) is easy to parse (does not require unbounded lookahead) and therefore easier to produce diagnostics for, and</div><div class="">(d) kept the parameter list and return values looking like they do in declarations (when types are included)</div><div class=""><br class=""></div><div class="">It may not be the prettiest thing in the language, but I'm not sure why any of your proposals are objectively better. The main thing we are missing is that closures do not look like standalone function declarations, but we decided that they're important enough that they need a lightweight syntax. (Compare with JavaScript for a language that did <i class="">not</i> prioritize this.)</div><div class=""><br class=""></div><div class="">I personally love trailing closures, both here and in Ruby, so I'd put that down to just as much a matter of opinion as closure syntax.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 22, 2015, at 19:48 , Alexander Regueiro 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=""><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="">The standard map syntax is directly inspired by that of C#.<div class=""><br class=""></div><div class="">For Swift, I’d be relatively happy with something like the following (repeating what’s already been said I believe)</div><div class=""><br class=""></div><div class="">map ({ x => x + 5 })</div><div class=""><br class=""></div><div class="">or using trailing closure</div><div class=""><br class=""></div><div class="">map { x => x + 5 }</div><div class=""><br class=""></div><div class="">with the possibility of an additional single-line option:</div><div class=""><br class=""></div><div class="">map ( x => x + 5 )</div><div class=""><br class=""></div><div class="">(which is useful in the case of non-trailing-closure expressions).</div><div class=""><br class=""></div><div class="">Of course, I’d rather remove trailing closures altogether, but I suspect that won’t happen. :(</div><div class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 23 Dec 2015, at 03:45, Craig Cruden <<a href="mailto:ccruden@novafore.com" class="">ccruden@novafore.com</a>> wrote:</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="">It has probably been 6 months since I have had time to do anything interesting (JDK6 + Oracle SQL recently for contracts recently) so if I am messing up terminology or syntax - please excuse me. I messed a few things up and had to open up an old Scala project to remind me what I was doing.<div class=""><br class=""></div><div class=""><br class=""></div><div class="">The standard map syntax for Scala is:</div><div class=""><br class=""></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>a.map(x => x + 5)</div><div class=""><br class=""></div><div class="">or using a placeholder (very limited shorthand - cannot use a placeholder twice for the same value):</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>a.map(_ + 5)</div><div class=""><br class=""></div><div class="">if it is a tuple then</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>a.map(x => f(x._1, x._2))</div><div class=""><br class=""></div><div class="">or you can pass in a function block (with pattern matching case)</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>a.map { case (x, y) => (y, x) }</div><div class=""><br class=""></div><div class="">there might be some mathematical reason behind the “in” keyword - but it is lost on me as well (it has been a good 30 years since University) and gets lost on me. If I had more time I might get use to it.</div><div class=""><br class=""></div><div class="">I hope I did not mess up those examples as bad.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""> </div><div class=""><br class=""></div><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On 2015-12-23, at 9:52:46, Andrey Tarantsov <<a href="mailto:andrey@tarantsov.com" class="">andrey@tarantsov.com</a>> wrote:</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=""><div class=""><blockquote type="cite" class=""><div class=""><div class="">foo.map( bar => bar.boz) // single line<br class=""></div></div></blockquote><div class=""><br class=""></div>Well how important is it to use () instead of {} here?</div><div class=""><br class=""></div><div class="">If you make it</div><div class=""><br class=""></div><div class="">foo.map { bar => bar.boz }</div><div class=""><br class=""></div><div class="">then it's like it is now, but with "in" replace by "=>".</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div class="">foo.map { (x, y) => x * 5 + y }<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I actually like the bare version:</div><div class=""><br class=""></div><div class="">foo.map { x, y => x * 5 + y }</div><div class=""><br class=""></div><div class="">but not in your example (here it looks atrocious). Take this real code, though:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo; min-height: 16px;" class=""><br class=""></div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo;" class=""> constrain(topBlock, tableView, view) { top, tbl, sup <span style="font-variant-ligatures: no-common-ligatures; color: #35568a" class="">in</span></div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo;" class=""> top.left == sup.left + horizPadding</div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo;" class=""> top.right == sup.right - horizPadding</div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo;" class=""> top.top == sup.top + topPadding</div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo; min-height: 16px;" class=""><br class=""></div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo;" class=""> tbl.top == top.bottom + <span style="font-variant-ligatures: no-common-ligatures; color: #35568a" class="">16</span></div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo;" class=""> tbl.bottom == sup.bottom</div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo; min-height: 16px;" class=""><br class=""></div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo;" class=""> tbl.left == sup.left + horizPadding - horizTableHang</div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo;" class=""> tbl.right == sup.right - horizPadding + horizTableHang</div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo;" class=""> }</div><div class=""><br class=""></div><div class="">I think the lack of parens is beneficial in reducing the visual noise here.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">And yes, I certainly would prefer `=>` rather than `in`.</blockquote><div class=""><br class=""></div><div class="">It seems like the community can actually agree on this.</div><div class=""><br class=""></div><div class="">Does anyone know if it has any parsing problems / grammar implications right now? </div><br class=""><blockquote type="cite" class=""> I think a big problem with `in` is that it’s textual, and doesn’t provide a clear visual separation from keywords/names at the start of the body or the end of the type specifier.</blockquote><div class=""><br class=""></div><div class="">Yes, agreed. “Not delimited enough”.</div><br class=""><blockquote type="cite" class=""> (Are the [parentheses] around `bar` in your example required? I’m ambivalent to them.)<br class=""></blockquote><div class=""><br class=""></div><div class="">No, they are not, as shown above.</div><br class=""><blockquote type="cite" class="">To be clear, I’m still not a fan of the Ruby syntax. I think it makes the parsing easier for a compiler but harder for a human…</blockquote><div class=""><br class=""></div><div class="">Depends on the human. To this specific human, the Ruby-style one is the easiest to parse (and mind you, I had <i class="">very</i> limited experience with Ruby compared to other languages, so it's not just being used to it, but rather an honest love and preference).</div><div class=""><br class=""></div><div class="">A.</div></div><div class=""><br class=""></div></div></div></div></div></blockquote></div><br class=""></div></div></div></div></div></blockquote></div><br class=""></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=ZEz4qHYnXhPr3bBPu-2FxP4tN3HfWKL-2FtJpqkQ0gkOVSBiQuT9iuV1NimW9Yj3Y6E5ln5Wd4qjoQzkQtt3XEiNaR5BBRv-2BcI7WOssCGwsHDZJkTf1VCQaCcYzU-2FXi35MOKtNCyJ3UwZAOCANGxBtQX0fsGKhk6ThRDkk86PFnWWxZzwBHix0YJajwSjp0B5MIcaknNFxDXOpIo3RNIW4cm68282C9fFcIB4e1-2FPP9hLFc-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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></body></html>