I think the way it is now works just fine. The only use-case I could see for this would be for having multiple closures, but in that case I think defining them before the function call is clearer anyway.
-thislooksfun (tlf) > On Jan 4, 2017, at 10:40 PM, Derrick Ho via swift-evolution > <[email protected]> wrote: > > So could we add a @trailing or @nontrailing to the block argument to toggle > on and off the feature? > > > On Wed, Jan 4, 2017 at 8:35 PM Douglas Gregor via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > > On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> Check out this thread >> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160606/020470.html>–it’s >> very similar to what you proposed, but it didn’t go anywhere. FWIW +1 to >> this as well as the ability to use multiple trailing closures like so: >> >> animate(identifier: “”, duration: 0, update: { >> // update >> }, completion: { >> // completion >> } >> >> Saagar Jha >> >> >> >>> On Jan 4, 2017, at 6:25 PM, Jay Abbott via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> When you have a function with a closure and then another optional default = >>> nil closure at the end, like this: >>> >>> open static func animate(identifier: String, >>> duration: Double, >>> update: @escaping AnimationUpdate, >>> completion: AnimationCompletion? = nil) { >>> You can’t use trailing closure syntax for the update argument when leaving >>> the completion argument out/default. >>> >>> This kind of breaks one of the benefits of default arguments, which is that >>> you can add them to existing released functions without breaking the >>> calling code. This means you have to add a separate convenience function >>> without the extra argument, which is annoying and inelegant. >>> > > Why not simply add the "completion" parameter before the trailing closure? > That would still allow existing callers to work, without having to change the > language. > >>> Another annoying thing is that you can easily miss this error if you happen >>> to not use trailing closure syntax in your tests or other usage, because >>> adding the extra default argument compiles fine for code that uses normal >>> syntax. >>> > > The Swift compiler warns when a parameter written as a closure type isn't the > last parameter. The warning is actually disabled in the specific case above > because you've written it using a typealias... maybe we should warn on such > cases (it's worth a bug report). Regardless, in the majority of instances, > you'll get a warning, so it won't be silent on disabling trailing closure > syntax. > >>> Are there any issues/gotchas if the trailing closure syntax were to work >>> for the last specified argument rather than the last defined argument? >>> > > The main gotcha, and the reason the rule is the way it is, is that it means > you'd lose trailing closure syntax if the caller wanted to specify an > argument for the last parameter. > > - Doug > > >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
