[swift-evolution] Lambda function syntax

Tue Dec 22 22:02:28 CST 2015

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.

We definitely thought a lot about closure syntax; what we ended up with
(a) is concise,
(b) has some precedent, structurally (Ruby, Smalltalk),
(c) is easy to parse (does not require unbounded lookahead) and therefore easier to produce diagnostics for, and
(d) kept the parameter list and return values looking like they do in declarations (when types are included)

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 not prioritize this.)

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.

Best,
Jordan

> On Dec 22, 2015, at 19:48 , Alexander Regueiro via swift-evolution <swift-evolution at swift.org> wrote:
> 
> The standard map syntax is directly inspired by that of C#.
> 
> For Swift, I’d be relatively happy with something like the following (repeating what’s already been said I believe)
> 
> map ({ x => x + 5 })
> 
> or using trailing closure
> 
> map { x => x + 5 }
> 
> with the possibility of an additional single-line option:
> 
> map ( x => x + 5 )
> 
> (which is useful in the case of non-trailing-closure expressions).
> 
> Of course, I’d rather remove trailing closures altogether, but I suspect that won’t happen. :(
> 
>> On 23 Dec 2015, at 03:45, Craig Cruden <ccruden at novafore.com <mailto:ccruden at novafore.com>> wrote:
>> 
>> 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.
>> 
>> 
>> The standard map syntax for Scala is:
>> 
>> 	a.map(x => x + 5)
>> 
>> or using a placeholder (very limited shorthand - cannot use a placeholder twice for the same value):
>> 
>> 	a.map(_ + 5)
>> 
>> if it is a tuple then
>> 
>> 	a.map(x => f(x._1, x._2))
>> 
>> or you can pass in a function block (with pattern matching case)
>> 
>> 	a.map { case (x, y) => (y, x) }
>> 
>> 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.
>> 
>> I hope I did not mess up those examples as bad.
>> 
>> 
>>  
>> 
>>> On 2015-12-23, at 9:52:46, Andrey Tarantsov <andrey at tarantsov.com <mailto:andrey at tarantsov.com>> wrote:
>>> 
>>>> foo.map( bar => bar.boz) // single line
>>> 
>>> Well how important is it to use () instead of {} here?
>>> 
>>> If you make it
>>> 
>>> foo.map { bar => bar.boz }
>>> 
>>> then it's like it is now, but with "in" replace by "=>".
>>> 
>>>> foo.map { (x, y) => x * 5 + y }
>>> 
>>> I actually like the bare version:
>>> 
>>> foo.map { x, y => x * 5 + y }
>>> 
>>> but not in your example (here it looks atrocious). Take this real code, though:
>>> 
>>> 
>>>         constrain(topBlock, tableView, view) { top, tbl, sup in
>>>             top.left  == sup.left + horizPadding
>>>             top.right == sup.right - horizPadding
>>>             top.top   == sup.top  + topPadding
>>> 
>>>             tbl.top    == top.bottom + 16
>>>             tbl.bottom == sup.bottom
>>> 
>>>             tbl.left  == sup.left + horizPadding - horizTableHang
>>>             tbl.right == sup.right - horizPadding + horizTableHang
>>>         }
>>> 
>>> I think the lack of parens is beneficial in reducing the visual noise here.
>>> 
>>>> And yes, I certainly would prefer `=>` rather than `in`.
>>> 
>>> It seems like the community can actually agree on this.
>>> 
>>> Does anyone know if it has any parsing problems / grammar implications right now? 
>>> 
>>>> 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.
>>> 
>>> Yes, agreed. “Not delimited enough”.
>>> 
>>>> (Are the [parentheses] around `bar` in your example required? I’m ambivalent to them.)
>>> 
>>> No, they are not, as shown above.
>>> 
>>>> 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…
>>> 
>>> Depends on the human. To this specific human, the Ruby-style one is the easiest to parse (and mind you, I had very limited experience with Ruby compared to other languages, so it's not just being used to it, but rather an honest love and preference).
>>> 
>>> A.
>>> 
>> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151222/ff17886a/attachment.html>