[swift-evolution] Deprecating Trailing Closures

[Radosław Pietruszewski]

> On 24 Mar 2016, at 18:57, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 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 don’t see how trailing closures, or lack thereof, is special enough to enforce like that. I mean, you could say that about so many features. Should we even allow “init?” and leave it up to personal preference, if only later will developers consider if it’s actually a good idea and they shouldn’t use “init throws”?

I’d be sad to see trailing closures go, but it’s a reasonable proposal to make. However, enforcing usage of trailing closures (a mainly stylistic choice that doesn’t even have the same safety concerns as the “remove implicit self” discussion) seems pointless.

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