I don't see any confusion with trailing closures vs if or guard.<br><br>If you claim that a long block of 50 lines is hard to digest then that probably means it needs to be broken down in to smaller pieces.<br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 15, 2017 at 8:27 AM Rien via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> On 15 Mar 2017, at 13:14, Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com" class="gmail_msg" target="_blank">adrian.zubarev@devandartist.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> 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.<br class="gmail_msg">
<br class="gmail_msg">
To me that only works for up to 50 or maybe 70 lines of code. If the modules get larger I tend to miss things that are not directly visible.<br class="gmail_msg">
<br class="gmail_msg">
> 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?<br class="gmail_msg">
<br class="gmail_msg">
Maybe, lets wait to see if more people think this is a real problem or not.<br class="gmail_msg">
<br class="gmail_msg">
Rien.<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> Something like:<br class="gmail_msg">
><br class="gmail_msg">
> func foo() -> Int {<br class="gmail_msg">
><br class="gmail_msg">
> label:<br class="gmail_msg">
><br class="gmail_msg">
> [1,2,3,4,5, …].forEach {<br class="gmail_msg">
><br class="gmail_msg">
> // Do something<br class="gmail_msg">
> // If certain condition is met abort and return from the parent scope<br class="gmail_msg">
> return(label) 42<br class="gmail_msg">
> }<br class="gmail_msg">
><br class="gmail_msg">
> return 0<br class="gmail_msg">
> }<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> --<br class="gmail_msg">
> Adrian Zubarev<br class="gmail_msg">
> Sent with Airmail<br class="gmail_msg">
><br class="gmail_msg">
> Am 15. März 2017 um 12:56:31, Rien (<a href="mailto:rien@balancingrock.nl" class="gmail_msg" target="_blank">rien@balancingrock.nl</a>) schrieb:<br class="gmail_msg">
><br class="gmail_msg">
>> Sorry, it seems we are talking past each other, let me try again:<br class="gmail_msg">
>><br class="gmail_msg">
>> I left the “if” out on purpose. To show that even though the snippet was “valid” code, it was in fact ambiguous.<br class="gmail_msg">
>><br class="gmail_msg">
>> With closures (and autoclosures) it becomes possible -to some extent- to “enhance” the language.<br class="gmail_msg">
>><br class="gmail_msg">
>> Consider:<br class="gmail_msg">
>><br class="gmail_msg">
>> guard let c = somefunc() else { showError(); return }<br class="gmail_msg">
>> myguard( let c = somefunc()) { showError(); return }<br class="gmail_msg">
>><br class="gmail_msg">
>> In this simple example it is clear that the second return behaves quite differently from the first.<br class="gmail_msg">
>> It gets more difficult if the code in the block cq closure gets very large.<br class="gmail_msg">
>> Also, I would expect that beginners would have problems understanding this (subtile but important) difference.<br class="gmail_msg">
>><br class="gmail_msg">
>> Regards,<br class="gmail_msg">
>> Rien<br class="gmail_msg">
>><br class="gmail_msg">
>> Site: <a href="http://balancingrock.nl" rel="noreferrer" class="gmail_msg" target="_blank">http://balancingrock.nl</a><br class="gmail_msg">
>> Blog: <a href="http://swiftrien.blogspot.com" rel="noreferrer" class="gmail_msg" target="_blank">http://swiftrien.blogspot.com</a><br class="gmail_msg">
>> Github: <a href="http://github.com/Balancingrock" rel="noreferrer" class="gmail_msg" target="_blank">http://github.com/Balancingrock</a><br class="gmail_msg">
>> Project: <a href="http://swiftfire.nl" rel="noreferrer" class="gmail_msg" target="_blank">http://swiftfire.nl</a><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> > On 15 Mar 2017, at 12:19, Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com" class="gmail_msg" target="_blank">adrian.zubarev@devandartist.com</a>> wrote:<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > There is no if … on my screen nor there is one here <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon%E2%80%9320170313/033888.html" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon–20170313/033888.html</a>. May be a typo?<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > In that case it cannot be a trailing closure because trailing closures are banned in such scenarios. <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md</a><br class="gmail_msg">
>> ><br class="gmail_msg">
>> > 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.<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > Let me know if I understood your gist now.<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > if someFunction { …; return } // someFunction cannot have a trailing closure here!<br class="gmail_msg">
>> ><br class="gmail_msg">
>> ><br class="gmail_msg">
>> ><br class="gmail_msg">
>> ><br class="gmail_msg">
>> > --<br class="gmail_msg">
>> > Adrian Zubarev<br class="gmail_msg">
>> > Sent with Airmail<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > Am 15. März 2017 um 12:08:19, Rien (<a href="mailto:rien@balancingrock.nl" class="gmail_msg" target="_blank">rien@balancingrock.nl</a>) schrieb:<br class="gmail_msg">
>> ><br class="gmail_msg">
>> >> If I wrote this:<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> if serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); return }<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> then the meaning of return would have been different.<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> 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.<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> 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.<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> Regards,<br class="gmail_msg">
>> >> Rien<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> Site: <a href="http://balancingrock.nl" rel="noreferrer" class="gmail_msg" target="_blank">http://balancingrock.nl</a><br class="gmail_msg">
>> >> Blog: <a href="http://swiftrien.blogspot.com" rel="noreferrer" class="gmail_msg" target="_blank">http://swiftrien.blogspot.com</a><br class="gmail_msg">
>> >> Github: <a href="http://github.com/Balancingrock" rel="noreferrer" class="gmail_msg" target="_blank">http://github.com/Balancingrock</a><br class="gmail_msg">
>> >> Project: <a href="http://swiftfire.nl" rel="noreferrer" class="gmail_msg" target="_blank">http://swiftfire.nl</a><br class="gmail_msg">
>> >><br class="gmail_msg">
>> >><br class="gmail_msg">
>> >><br class="gmail_msg">
>> >><br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> > On 15 Mar 2017, at 12:00, Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com" class="gmail_msg" target="_blank">adrian.zubarev@devandartist.com</a>> wrote:<br class="gmail_msg">
>> >> ><br class="gmail_msg">
>> >> > 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.<br class="gmail_msg">
>> >> ><br class="gmail_msg">
>> >> > You can simply write this if you wanted to:<br class="gmail_msg">
>> >> ><br class="gmail_msg">
>> >> > myFucntion(someLabel: abc, closureLabel: { …; return })<br class="gmail_msg">
>> >> ><br class="gmail_msg">
>> >> > Parentheses are indicating that your closure is immediately invoked.<br class="gmail_msg">
>> >> ><br class="gmail_msg">
>> >> > let someInt = { return 42 }()<br class="gmail_msg">
>> >> > print(someInt)<br class="gmail_msg">
>> >> ><br class="gmail_msg">
>> >> > let someClosureWhichReturnsAnInt = { return 42 } // You can reuse the closure<br class="gmail_msg">
>> >> > print(someClosureWhichReturnsAnInt()) // Invocation happens now here<br class="gmail_msg">
>> >> ><br class="gmail_msg">
>> >> > 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.<br class="gmail_msg">
>> >> ><br class="gmail_msg">
>> >> ><br class="gmail_msg">
>> >> ><br class="gmail_msg">
>> >> ><br class="gmail_msg">
>> >> > --<br class="gmail_msg">
>> >> > Adrian Zubarev<br class="gmail_msg">
>> >> > Sent with Airmail<br class="gmail_msg">
>> >> ><br class="gmail_msg">
>> >> > Am 15. März 2017 um 11:35:39, Rien via swift-evolution (<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>) schrieb:<br class="gmail_msg">
>> >> ><br class="gmail_msg">
>> >> >> What does the following code fragment do?<br class="gmail_msg">
>> >> >><br class="gmail_msg">
>> >> >> serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); return }<br class="gmail_msg">
>> >> >><br class="gmail_msg">
>> >> >> The only possible answer is: I don’t know.<br class="gmail_msg">
>> >> >><br class="gmail_msg">
>> >> >> The problem is finding out what the “return” statement will do.<br class="gmail_msg">
>> >> >><br class="gmail_msg">
>> >> >> 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.<br class="gmail_msg">
>> >> >><br class="gmail_msg">
>> >> >> This could be disambiguated by using the same syntax as for lazy variables:<br class="gmail_msg">
>> >> >><br class="gmail_msg">
>> >> >> serverCert.write(to: serverCertificateUrl) { showErrorInKeyWindow(message: message); return }()<br class="gmail_msg">
>> >> >><br class="gmail_msg">
>> >> >> Now it is clear that the return statement will only terminate the (trailing) closure.<br class="gmail_msg">
>> >> >><br class="gmail_msg">
>> >> >> A question to the educators on the list: Is this a real problem?<br class="gmail_msg">
>> >> >><br class="gmail_msg">
>> >> >> Personally, I dislike this situation, but I am also ambivalent towards the solution I just described.<br class="gmail_msg">
>> >> >><br class="gmail_msg">
>> >> >> Regards,<br class="gmail_msg">
>> >> >> Rien<br class="gmail_msg">
>> >> >><br class="gmail_msg">
>> >> >> Site: <a href="http://balancingrock.nl" rel="noreferrer" class="gmail_msg" target="_blank">http://balancingrock.nl</a><br class="gmail_msg">
>> >> >> Blog: <a href="http://swiftrien.blogspot.com" rel="noreferrer" class="gmail_msg" target="_blank">http://swiftrien.blogspot.com</a><br class="gmail_msg">
>> >> >> Github: <a href="http://github.com/Balancingrock" rel="noreferrer" class="gmail_msg" target="_blank">http://github.com/Balancingrock</a><br class="gmail_msg">
>> >> >> Project: <a href="http://swiftfire.nl" rel="noreferrer" class="gmail_msg" target="_blank">http://swiftfire.nl</a><br class="gmail_msg">
>> >> >><br class="gmail_msg">
>> >> >><br class="gmail_msg">
>> >> >><br class="gmail_msg">
>> >> >><br class="gmail_msg">
>> >> >><br class="gmail_msg">
>> >> >> _______________________________________________<br class="gmail_msg">
>> >> >> swift-evolution mailing list<br class="gmail_msg">
>> >> >> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
>> >> >> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
>> >><br class="gmail_msg">
>><br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>