On 3/24/16 13:59, Erica Sadun via swift-evolution wrote:
>> 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 find trailing closures extremely valuable for APIs like GCD and
NSURLSession and derivates. No more dangling )s.
It's probably my own (style) fault, but in ObjC I sometimes see lines like
})]}));
making my own code become read-only :-)
--
Rainer Brockerhoff <[email protected]>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
