> On 15 Mar 2017, at 13:04, Jaden Geller <[email protected]> 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. > 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 >> <[email protected]> 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 <[email protected]> >>> 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 ([email protected]) 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 >>>>> <[email protected]> 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 >>>>> ([email protected]) 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 >>>>>> [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
