Sent from my iPhone

> On Jan 4, 2017, at 8:40 PM, Derrick Ho <[email protected]> wrote:
> 
> So could we add a @trailing or @nontrailing to the block argument to toggle 
> on and off the feature?

 But... why? That's a nontrivial amount of complexity for a fairly limited use 
case. 

  - Doug

> 
> 
>> On Wed, Jan 4, 2017 at 8:35 PM Douglas Gregor via swift-evolution 
>> <[email protected]> wrote:
>> 
>>> On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution 
>>> <[email protected]> wrote:
>>> 
>>> Check out this thread–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]> 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]
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to