> On Mar 24, 2016, at 10:41 AM, Haravikk via swift-evolution
> <[email protected]> wrote:
>
>>
>> On 24 Mar 2016, at 16:13, William Dillon <[email protected]
>> <mailto:[email protected]>> wrote:
>> 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.
I follow the "Rule of Kevin", which is not language enforced. Parens around
functional
closures (->T), not around procedural (->Void) ones. This promotes "language
construct"-like
Void calls, avoids compiler parsing issues when chaining (or using "guard",
"if", etc). It lets
me know instantly how the closure is used.
While I was originally reluctant to adopt it, its advantages have become
self-evident over time.
This ends up being slightly wordier, especially in the few cases you need to
use argument labels.
I think it's worth it.
-- E
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
