> 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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution