I don't see any confusion with trailing closures vs if or guard. 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. On Wed, Mar 15, 2017 at 8:27 AM Rien via swift-evolution < [email protected]> wrote:
> > > On 15 Mar 2017, at 13:14, Adrian Zubarev < > [email protected]> wrote: > > > > 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. > > 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. > > > 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? > > Maybe, lets wait to see if more people think this is a real problem or not. > > Rien. > > > > > 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 ([email protected]) 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 < > [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
