> On Mar 24, 2016, at 11:57 AM, Haravikk <swift-evolut...@haravikk.me> wrote:
>
>
>> On 24 Mar 2016, at 16:59, Erica Sadun <er...@ericasadun.com
>> <mailto:er...@ericasadun.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.
>
> That’s a pretty good rule, and I think it’s what I’m now doing myself as
> well. Any thoughts on whether it should be enforced, though?
> There’s a thread currently about allowing trailing closures within guard
> etc., but personally I think that that’s a bad idea, and that it may actually
> be better to head in the opposite direction (use them less), but currently
> it’s an automatic feature which I’m not sure is a good thing.
>
> Given your “Rule of Kevin” we could have the a rule for closures as a last
> parameter that if they have a non-Void return type, they must add a new
> @trailing attribute, otherwise trailing is implied.
>
>
> I realise there’s an argument to be made that it should just be up to linters
> or personal preference, but I’m concerned that many developers like myself
> will use trailing closures everywhere they’re permitted because it seems like
> the right thing to do, and only later start to consider whether it’s a good
> idea to actually use them in specific cases. But for consistency’s sake I’d
> say it’s not good to use them except for language construct type calls (like
> .forEach actually, which I always forget about too), which is where the main
> advantage lies.
I'm agnostic on enforcement. I'm unthrilled about adding `@trailing`.
-- E
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
