[swift-evolution] Lambda function syntax
Andrey Tarantsov
andrey at tarantsov.com
Tue Dec 22 20:52:46 CST 2015
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151223/9de281d0/attachment.html>
More information about the swift-evolution
mailing list