>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
