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.)
Jordan
···
On Jun 8, 2016, at 12:06, Matt Neuburg via swift-evolution <swift-evolution@swift.org> wrote:
Stop me if you've heard this one; I've only just joined the list, in order to raise it.
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.
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`."
If we may take leave of practical considerations for a moment, I'd like to note that the ideal syntax for a call like this would probably look like:
I'm guessing this isn't possible because the `completion` could instead be a call to a separate function with a trailing closure. But is there some way we could get something similar? That could significantly improve our handling of multi-block APIs and give trailing closures the ability to emulate more kinds of syntax.
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. Bad design
2. Multiple closures
3. Design before Swift / ObjC focused
To which:
1. Well, not sure that should be "fixed"
2. I think multiple closures should all be treated the same without trailing
3's a different kind of thing. I vaguely endorse having Cocoa request how it should be imported beyond the SE-0005 rules.
We were kicking around some ideas on "how should defaults embetter" that this kind of relates to: CocoaDefaults.md · GitHub In this example, I can see a rule of "if there's only one closure named animation, completion, etc, promote it to the last argument". Kind of.
-- E, dithery
···
On Jun 8, 2016, at 4:11 PM, Matt Neuburg via swift-evolution <swift-evolution@swift.org> wrote:
Well, I guess I didn't pick a strong enough case. Try this one:
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
···
On Jun 8, 2016, at 10:46 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
On Jun 8, 2016, at 12:06, Matt Neuburg via swift-evolution <swift-evolution@swift.org> wrote:
On Thu, Jun 9, 2016 at 1:06 AM Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote:
> 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`."
If we may take leave of practical considerations for a moment, I'd like to
note that the ideal syntax for a call like this would probably look like:
I'm guessing this isn't possible because the `completion` could instead be
a call to a separate function with a trailing closure. But is there some
way we could get something similar? That could significantly improve our
handling of multi-block APIs and give trailing closures the ability to
emulate more kinds of syntax.
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:
Both of those forms seem readable to me. I’d hate to rule them out.
+1
-Thorsten
···
Am 08.06.2016 um 22:59 schrieb Paul Cantrell via swift-evolution <swift-evolution@swift.org>:
On Jun 8, 2016, at 3:46 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
On Jun 8, 2016, at 12:06, Matt Neuburg via swift-evolution <swift-evolution@swift.org> wrote:
Okay, so having had this idea spat back in my face, I was so discouraged by the treatment here that I basically left this forum and never made another suggestion again. And now (Swift 5.3) the very same idea is an accepted proposal that Apple is touting as a major new Swift feature. Oh the irony.
I don't see anything that could be characterised as someone spitting in your face here, just respectful discussion of various options and people agreeing or disagreeing, so I think you should retract this. And the accepted proposal for multiple trailing closures isn't at all the same as your proposal here, which was about how single trailing closures are matched in the presence of default values for closure parameters, though it is similar to @beccadax's and @saagarjha's suggestions.