> On 24 Mar 2016, at 16:59, Erica Sadun <[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.
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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
