[swift-evolution] Code blocks and trailing closures

Jaden Geller jaden.geller at gmail.com
Wed Mar 15 07:22:34 CDT 2017 

> On Mar 15, 2017, at 5:17 AM, Rien <Rien at Balancingrock.nl> wrote:
> 
> 
>> On 15 Mar 2017, at 13:04, Jaden Geller <jaden.geller at gmail.com> wrote:
>> 
>> It seems like your complaint is that control-flow statements, specifically `return`, act different inside closures than inside other braced statements.
> 
> Yes.
> break and continue also come to mind.
> 
> For example if you have some nested loops and you see a “break” statement, you must inspect the code between the loop start and the “break" to check if the break is inside a closure or not.
> 
> 
>> I too dislike this inconsistency, but I don’t think that the syntactic change you suggested makes it much more clear.
> 
> Agree.
> 
> As is probably clear from Adrian’s reaction, I am not sure if this really is a problem.
> I don’t like it, but the current situation is workable even though it might be confusing to newbies.

Yeah, either way, I don’t think this is a particularly pressing issue for Swift to address in the next few versions.

Just for fun though, check out Ruby! It allows for both lambdas and anonymous procedures, that latter of which don’t “capture” control-flow keywords. If you say `return` inside a procedure, it’ll return from the function that that called the procedure, not the procedure (aka, if/for/while behavior in Swift)!

> 
>> I’d rather find a solution that’d allow trailing closure functions (like `forEach`) to support keywords like `return`, though I imagine this would require some sort of macro system.
>> 
>> Cheers,
>> Jaden Geller
>> 
>>> On Mar 15, 2017, at 4:56 AM, Rien via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 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 
>>>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>

More information about the swift-evolution mailing list