> On 24 Mar 2016, at 16:13, William Dillon <will...@housedillon.com> wrote:
>
>> On Mar 24, 2016, at 7:18 AM, Kurt Werle via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> Coming from ruby, I'm quite fond of trailing closures. I couldn't really
>> give you a concrete reason why - putting them in the ()'s really isn't that
>> big a deal. But I'll say that I move them outside every single time...
>>
>> I will say that your examples are the most trivial possible and that the
>> more complex the closure (describing context variables and return types,
>> throws, etc) the uglier it seem to me to put it inside parens.
>>
>
> Agree.
>
> Another thing I like about trailing closures is that it allows me to make
> custom constructs that feel more like a part of the language. For example, I
> really love this extension for NSLock that I have:
>
> extension NSLock {
> func protect(action: (Void) -> Void) {
> self.lock()
> action()
> self.unlock()
> }
> }
>
> Now, whenever I need to use my lock, I can just do:
>
> peersLock.protect {
> outputString += "\(self.peers.count) peers:\n"
> for (_, peer) in self.peers {
> outputString += "\(peer)\n"
> }
> }
>
> To me, it looks cleaner to me to not have this paren dangling around at the
> end. On this one I’d definitely say that if you don’t like it, don’t use it.
> I don’t *think* that you’re forced to use it anywhere. It’s a hard sell to
> take it away from everyone.
>
> - Will
I’m not proposing to remove them entirely, in fact your lock example is a
perfect example of when a trailing closure makes the most sense, as a form of
customised language feature. But I’m wondering if perhaps cases like these
should be created using an attribute that specifically enables it? e.g- your
definition could become:
func protect(action: @trailing (Void) -> Void) { … }
It’s other cases like common usages of .map() and similar methods where I’ve
found myself using the closure in its trailing form less and less, and am not
as sure if it’s really needed, or may actually be more of a detriment to the
language than a benefit._______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
