[swift-evolution] Deprecating Trailing Closures

Erica Sadun erica at ericasadun.com
Thu Mar 31 09:08:01 CDT 2016


> On Mar 31, 2016, at 5:56 AM, Radosław Pietruszewski <radexpl at gmail.com> wrote:
>> 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

Following a style rule is just like using a linter. It's not language mandated and I have not argued for enforcement.

-- E

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160331/3dbc1283/attachment.html>


More information about the swift-evolution mailing list