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 <[email protected]> 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 <[email protected]
>> <mailto:[email protected]>> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
