> Am 08.06.2016 um 22:59 schrieb Paul Cantrell via swift-evolution > <[email protected]>: > > >>> 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.
+1 -Thorsten > > Cheers, P > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
