> 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
