[swift-evolution] Deprecating Trailing Closures

[Rainer Brockerhoff]

On 3/24/16 13:59, Erica Sadun via swift-evolution wrote:
>> On Mar 24, 2016, at 10:41 AM, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
>>
>>>
>>> On 24 Mar 2016, at 16:13, William Dillon <william at housedillon.com <mailto:william at housedillon.com>> 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  <rainer at brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/