[swift-evolution] Code blocks and trailing closures

[Adrian Zubarev]

I still don’t see your point there. In general you won’t look at parts of parts of a code. Instead you’ll take a chunk that is valid and not ambiguous from the readers perspective. Beginners will bump into that issue, because it’s simply meant to be. Everyone has to lean the difference between break, continue and return in guarded statements and loops. We already have labels to exit specific nested loops. Maybe that is also the way return could go?

Something like:

func foo() -> Int {
     
label:

    [1,2,3,4,5, …].forEach {  
     
        // Do something
        // If certain condition is met abort and return from the parent scope
        return(label) 42     
    }
     
    return 0
}


-- 
Adrian Zubarev
Sent with Airmail

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

Sorry, it seems we are talking past each other, let me try again:  

I left the “if” out on purpose. To show that even though the snippet was “valid” code, it was in fact ambiguous.  

With closures (and autoclosures) it becomes possible -to some extent- to “enhance” the language.  

Consider:  

guard let c = somefunc() else { showError(); return }  
myguard( let c = somefunc()) { showError(); return }  

In this simple example it is clear that the second return behaves quite differently from the first.  
It gets more difficult if the code in the block cq closure gets very large.  
Also, I would expect that beginners would have problems understanding this (subtile but important) difference.  

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:19, Adrian Zubarev <adrian.zubarev at devandartist.com> wrote:  
>  
> 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/310aef9e/attachment.html>