> On 24 Mar 2016, at 18:57, Haravikk via swift-evolution
> <swift-evolution@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
