Hell, we have Unicode support, why not λ (U+03BB)? Seriously though, for a
C-like language I have to agree that Swift's approach is one of the best. I
can't think of a way of improving it that wouldn't immediately clash with the
style and syntax of the language. Sure you could change a few keywords here
and there, but fundamentally
{ args in body }
Strikes a balance between C-like basic blocks and Objective-C-like blocks.
When you start making more of this implicit or shifting it around, you have to
necessarily start caring about things like whitespace and implicit scoping (I
notice in the example you give, it is immediately less clear which identifiers
are bound into what block). Things I don't think Swift wants you to care about,
or makes explicit where you should. Losing a few characters here and there
doesn't seem worth it to lose an equal amount of declarative-ness.
~Robert Widmann
2015/12/27 17:24、Brent Royal-Gordon via swift-evolution
<[email protected]> のメッセージ:
>> In this mail I’m answering several statements made in this thread by
>> different people, not only Brent’s mail from which I just picked the
>> following snippet:
>>
>>> let names = people.map => person { person.name }
>>
>> For me that is more difficult to read than
>>
>> let names = people.map { person in person.name }
>>
>> Especially when chaining is used, i.e.
>>
>> let names = people.filter => person { person.isFriend }.map => person {
>> person.name }
>>
>> (or would I have to add parentheses somewhere with this proposed syntax?)
>>
>> vs.
>>
>> let names = people.filter { person in person.isFriend }.map { person in
>> person.name }
>
> I said in the email that => is too visually heavy for this role.
>
> Here's something lighter, although I'm still not satisfied with it, and not
> seriously suggesting it:
>
> let names = people.map ~ person { person.name }
>
> Or even:
>
> let names = people.map \person { person.name }
>
> However, I'm really struggling to find anything that I actually like here.
> This may be one of those cases where we dislike what's there and explore a
> bunch of options, only to find out that the current thing actually is the
> least bad alternative after all.
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
