[swift-evolution] Deprecating Trailing Closures

[Radosław Pietruszewski]

>> 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.

I don’t follow the Rule of Kevin myself, although I’m not against it either, and I see why some people would like it.

But, if we’re going to have trailing closures at all (which seems desirable for creating things that look like language features), enforcement based on syntactic preference doesn’t make sense to me.

This really reminds me of a “remove implicit self” discussion. Some people (me included) were against, because they disliked the noisiness of “self” everywhere. Others argued that the implicitness is somewhat unsafe. A valid position to take. But it’s a kind of thing teams can use a linter for, if they want to enforce it as a rule.

Trailing closures seem like a similar thing. We could remove it altogether (although I think that would be a shame), or let’s just leave it up to preference (and developing guidelines) on where to use them.

Best,
— Radek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160331/c75f7e8e/attachment.html>