[swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax
Derrick Ho
wh1pch81n at gmail.com
Wed Jan 4 22:40:04 CST 2017
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 <
swift-evolution at swift.org> wrote:
>
> On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution <
> swift-evolution at 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 at 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.
>
> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170105/aa68b7e1/attachment.html>
More information about the swift-evolution
mailing list