Saagar Jha
> On Jan 4, 2017, at 8:35 PM, Douglas Gregor <dgre...@apple.com> wrote: > > > On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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. Tried this out in the playground: func foo(a: () -> (), b: (() -> ())? = nil) { a() b?() } foo(a: { print(“Bar”) }) and didn’t receive a warning for it, either. > >>> Are there any issues/gotchas if the trailing closure syntax were to work >>> for the last specified argument rather than the last definedargument? >>> > 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 >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
