> On Jun 8, 2016, at 3:46 PM, Jordan Rose via swift-evolution
> <[email protected]> wrote:
>
>>
>> On Jun 8, 2016, at 12:06, Matt Neuburg via swift-evolution
>> <[email protected]> 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.
Cheers, P
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
