Just reread my reply and found it a bit unclear, so I'm trying to fix that below :-)
> Am 28.12.2015 um 07:08 schrieb Thorsten Seitz via swift-evolution > <[email protected]>: > > > Am 27.12.2015 um 23:24 schrieb 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. > > Sorry, I overlooked that. > >> Here's something lighter, although I'm still not satisfied with it, and not >> seriously suggesting it: >> >> let names = people.map ~ person { person.name } > > Symbols have this problem in general because they stand out. But the real > problem comes from moving the parameters out of the braces. The symbol only > highlights it. What I wanted to say here is not that there is a problem with symbols standing out in general as that is an advantage in general and the very reason to use a symbol, but here it is a problem, because the symbol is in the wrong position here, so that it breaks the whole expression into the wrong pieces when chaining such calls which is a common thing to do, I'd say. -Thorsten >> 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. > > :-) > > -Thorsten > _______________________________________________ > 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
