[swift-evolution] extend trailing closure rule

[Thorsten Seitz]

> Am 08.06.2016 um 22:59 schrieb Paul Cantrell via swift-evolution <swift-evolution at swift.org>:
> 
> 
>>> On Jun 8, 2016, at 3:46 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>> On Jun 8, 2016, at 12:06, Matt Neuburg via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> Stop me if you've heard this one; I've only just joined the list, in order to raise it.
>>> 
>>> Here's a common thing to say:
>>> 
>>>   UIView.animate(withDuration:0.4, animations: {
>>>       self.v.backgroundColor = UIColor.red()
>>>   })
>>> 
>>> That's ugly. I'd rather write:
>>> 
>>>   UIView.animate(withDuration:0.4) {
>>>       self.v.backgroundColor = UIColor.red()
>>>   }
>>> 
>>> What stops me is that `animations:` is not eligible for trailing closure syntax, because it isn't the last parameter — `completion:` is. But `completion:` has a default value, namely `nil` — that's why I'm allowed to omit it. So why can't the compiler work its way backwards through the parameters, and say to itself: "Well, I see a trailing closure, and I don't see any `animations:` label or any `completion:` label, so this trailing closure must be the `animations:` argument and the `completions:` argument must be `nil`."
>>> 
>>> The idea is that this would work for _any_ function call where the function takes, as its last parameters, a series of function arguments that have default values. There can be only one trailing closure, so it should be assumed to occupy the first available slot, as it were.
>>> 
>>> Would this be viable? Would it make a decent proposal? m.
>> 
>> I'm one of those in favor of going the other way: if a function takes multiple closure arguments, you shouldn't be allowed to use a trailing closure at all, because it may not be obvious to readers of your code which one you are using. (This is especially true if the closures have the same signature.)
> 
> I’m not in favor of that. Good argument labeling can make it perfectly clear to readers.
> 
> Siesta even leans on this feature a bit in one of its API methods:
> 
>     configure(whenURLMatches: { $0 != authentication.url }) {
>         $0.config.headers["authentication-token"] = self.accessToken
>     }
> 
> …with this local refactoring if the first closure grows unwieldy:
> 
>     let specialFancyResources = {
>         // Special fancy matching goes here
>     }
>     
>     configure(whenURLMatches: specialFancyResources) {
>         $0.config.headers["authentication-token"] = self.accessToken
>     }
> 
> Both of those forms seem readable to me. I’d hate to rule them out.

+1

-Thorsten 


> 
> Cheers, P
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160609/519192b1/attachment.html>