Extend trailing closure rule

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.)

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.

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.

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.

Actually you can. UIView has three signatures ‘animateWithduration’:

class func animateWithDuration(_ duration: NSTimeInterval (file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_DataTypes/index.html#//apple_ref/swift/tdef/c:@T@NSTimeInterval),
                    animations animations: () -> Void (file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Swift/Reference/Swift_StandardLibrary_TypeAliases/index.html#//apple_ref/swift/tdef/s:s4Void))

class func animateWithDuration(_ duration: NSTimeInterval (file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_DataTypes/index.html#//apple_ref/swift/tdef/c:@T@NSTimeInterval),
                    animations animations: () -> Void (file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Swift/Reference/Swift_StandardLibrary_TypeAliases/index.html#//apple_ref/swift/tdef/s:s4Void),
                    completion completion: ((Bool (file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Swift/Reference/Swift_Bool_Structure/index.html#//apple_ref/swift/struct/s:Sb)) -> Void (file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Swift/Reference/Swift_StandardLibrary_TypeAliases/index.html#//apple_ref/swift/tdef/s:s4Void))?)

class func animateWithDuration(_ duration: NSTimeInterval (file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_DataTypes/index.html#//apple_ref/swift/tdef/c:@T@NSTimeInterval),
                         delay delay: NSTimeInterval (file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_DataTypes/index.html#//apple_ref/swift/tdef/c:@T@NSTimeInterval),
                       options options: UIViewAnimationOptions (file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/UIKit/Reference/UIView_Class/index.html#//apple_ref/swift/struct/c:@E@UIViewAnimationOptions),
                    animations animations: () -> Void (file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Swift/Reference/Swift_StandardLibrary_TypeAliases/index.html#//apple_ref/swift/tdef/s:s4Void),
                    completion completion: ((Bool (file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Swift/Reference/Swift_Bool_Structure/index.html#//apple_ref/swift/struct/s:Sb)) -> Void (file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Swift/Reference/Swift_StandardLibrary_TypeAliases/index.html#//apple_ref/swift/tdef/s:s4Void))?)

so your version is valid.

Best regards,
Rimantas

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:

  UIView.animate(withDuration: 0.4) {
    // animations
  }
  completion { finished in
    // completion
  }

And of course, since `completion` has a default value, this would naturally degrade to:

  UIView.animate(withDuration: 0.4) {
    // animations
  }

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.

···

--
Brent Royal-Gordon
Architechies

Well, I guess I didn't pick a strong enough case. Try this one:

        UIView.animate(withDuration:0.4, delay: 0, options: [.autoreverse]) {
            self.view.backgroundColor = UIColor.red()
        }

That doesn't compile. I'm suggesting that it would be cool if it did. m.

···

On Jun 8, 2016, at 12:29 PM, Rimantas Liubertas <rimantas@gmail.com> wrote:

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.

Actually you can. UIView has three signatures ‘animateWithduration’:

class func animateWithDuration(_ duration: NSTimeInterval,
                    animations animations: () -> Void)

class func animateWithDuration(_ duration: NSTimeInterval,
                    animations animations: () -> Void,
                    completion completion: ((Bool) -> Void)?)

class func animateWithDuration(_ duration: NSTimeInterval,
                         delay delay: NSTimeInterval,
                       options options: UIViewAnimationOptions,
                    animations animations: () -> Void,
                    completion completion: ((Bool) -> Void)?)

so your version is valid.

Best regards,
Rimantas

--
matt neuburg, phd = Matt Neuburg’s Home Page
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 9! Programming iOS 9 [Book]
iOS 9 Fundamentals! iOS 9 Programming Fundamentals with Swift [Book]
RubyFrontier! RubyFrontier Documentation

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

···

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:

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.)

Mid-call closure can mean one of several things:

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:

       UIView.animate(withDuration:0.4, delay: 0, options: [.autoreverse]) {
           self.view.backgroundColor = UIColor.red()
       }

That doesn't compile. I'm suggesting that it would be cool if it did. m.

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

···

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:

Jordan

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

How about using a colon to separate it, to make `completion` look like an
argument and to separate it from being a function? Something like this:

UIView.animate(withDuration: 0.4) {
// animations
}
completion: { finished in
// completion
}

···

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:

        UIView.animate(withDuration: 0.4) {
                // animations
        }
        completion { finished in
                // completion
        }

And of course, since `completion` has a default value, this would
naturally degrade to:

        UIView.animate(withDuration: 0.4) {
                // animations
        }

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.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Saagar Jha

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

···

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:

Cheers, P

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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.

4 Likes

Swift evolution can be strange indeed — that's life ;-)

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.

4 Likes