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