[swift-evolution] Code blocks and trailing closures

Adrian Zubarev adrian.zubarev at devandartist.com
Wed Mar 15 06:19:17 CDT 2017


There is no if … on my screen nor there is one here https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon–20170313/033888.html. May be a typo?

In that case it cannot be a trailing closure because trailing closures are banned in such scenarios. https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md

As for the lazy variables you’ve mentioned in the original posts, the closure there is invoked lately but only once and it cannot be reused at all.

Let me know if I understood your gist now.

if someFunction { …; return } // someFunction cannot have a trailing closure here!


-- 
Adrian Zubarev
Sent with Airmail

Am 15. März 2017 um 12:08:19, Rien (rien at balancingrock.nl) schrieb:

If I wrote this:  

if serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); return }  

then the meaning of return would have been different.  

Imo it is a problem that two pieces of code impact the understanding of each other and that those two pieces of code could potentially be very far apart.  

I do agree that the parenthesis are not a perfect solution, it was just the first thing that I could think of and that has some level of similarity in meaning.  

Regards,  
Rien  

Site: http://balancingrock.nl  
Blog: http://swiftrien.blogspot.com  
Github: http://github.com/Balancingrock  
Project: http://swiftfire.nl  





> On 15 Mar 2017, at 12:00, Adrian Zubarev <adrian.zubarev at devandartist.com> wrote:  
>  
> I’m slightly confused by this. How is a trailing closure different from a code block in Swift? It’s basically the same thing with some extra syntax sugar because it happens to be the last parameter of your function.  
>  
> You can simply write this if you wanted to:  
>  
> myFucntion(someLabel: abc, closureLabel: { …; return })  
>  
> Parentheses are indicating that your closure is immediately invoked.  
>  
> let someInt = { return 42 }()  
> print(someInt)  
>  
> let someClosureWhichReturnsAnInt = { return 42 } // You can reuse the closure  
> print(someClosureWhichReturnsAnInt()) // Invocation happens now here  
>  
> return is scope based and it’s totally clear (to me) that in your case return will return from your closure with a value of Void.  
>  
>  
>  
>  
> --  
> Adrian Zubarev  
> Sent with Airmail  
>  
> Am 15. März 2017 um 11:35:39, Rien via swift-evolution (swift-evolution at swift.org) schrieb:  
>  
>> What does the following code fragment do?  
>>  
>> serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); return }  
>>  
>> The only possible answer is: I don’t know.  
>>  
>> The problem is finding out what the “return” statement will do.  
>>  
>> Without knowing if the {...} is a code block or a trailing closure it is impossible to know what the return statement will do. It will either end the closure or it will end the function that contains this code block.  
>>  
>> This could be disambiguated by using the same syntax as for lazy variables:  
>>  
>> serverCert.write(to: serverCertificateUrl) { showErrorInKeyWindow(message: message); return }()  
>>  
>> Now it is clear that the return statement will only terminate the (trailing) closure.  
>>  
>> A question to the educators on the list: Is this a real problem?  
>>  
>> Personally, I dislike this situation, but I am also ambivalent towards the solution I just described.  
>>  
>> Regards,  
>> Rien  
>>  
>> Site: http://balancingrock.nl  
>> Blog: http://swiftrien.blogspot.com  
>> Github: http://github.com/Balancingrock  
>> Project: http://swiftfire.nl  
>>  
>>  
>>  
>>  
>>  
>> _______________________________________________  
>> 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/20170315/df16a201/attachment-0001.html>


More information about the swift-evolution mailing list