> On 31 Mar 2016, at 16:08, Erica Sadun <[email protected]> wrote:
> 
>> 
>> On Mar 31, 2016, at 5:56 AM, Radosław Pietruszewski <[email protected] 
>> <mailto:[email protected]>> 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

Apologies, I didn’t mean to suggest you argued for enforcement. Just adding my 
2¢ about why enforcement makes no sense to me.

Best,
— Radek
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to