[swift-evolution] extend trailing closure rule

[L. Mihalkovic]

> On Jun 8, 2016, at 10: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.)

+1


> 
> Jordan
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution