<html><head><style>
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
padding:1em;
margin:auto;
background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
font-weight: bold;
}
h1 {
color: #000000;
font-size: 28pt;
}
h2 {
border-bottom: 1px solid #CCCCCC;
color: #000000;
font-size: 24px;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777777;
background-color: inherit;
font-size: 14px;
}
hr {
height: 0.2em;
border: 0;
color: #CCCCCC;
background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
a, a:visited {
color: #4183C4;
background-color: inherit;
text-decoration: none;
}
#message {
border-radius: 6px;
border: 1px solid #ccc;
display:block;
width:100%;
height:60px;
margin:6px 0px;
}
button, #ws {
font-size: 12 pt;
padding: 4px 6px;
border-radius: 5px;
border: 1px solid #bbb;
background-color: #eee;
}
code, pre, #ws, #message {
font-family: Monaco;
font-size: 10pt;
border-radius: 3px;
background-color: #F8F8F8;
color: inherit;
}
code {
border: 1px solid #EAEAEA;
margin: 0 2px;
padding: 0 5px;
}
pre {
border: 1px solid #CCCCCC;
overflow: auto;
padding: 4px 8px;
}
pre > code {
border: 0;
margin: 0;
padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><p>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. Beginners will bump into that issue, because it’s simply meant to be. Everyone has to lean the difference between <code>break</code>, <code>continue</code> and <code>return</code> in guarded statements and loops. We already have labels to exit specific nested loops. Maybe that is also the way <code>return</code> could go?</p>
<p>Something like:</p>
<pre><code class="swift">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
}
</code></pre>
<p></p></div><div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1489579403132783872" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 15. März 2017 um 12:56:31, Rien (<a href="mailto:rien@balancingrock.nl">rien@balancingrock.nl</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>Sorry, it seems we are talking past each other, let me try again:
<br>
<br>I left the “if” out on purpose. To show that even though the snippet was “valid” code, it was in fact ambiguous.
<br>
<br>With closures (and autoclosures) it becomes possible -to some extent- to “enhance” the language.
<br>
<br>Consider:
<br>
<br>guard let c = somefunc() else { showError(); return }
<br>myguard( let c = somefunc()) { showError(); return }
<br>
<br>In this simple example it is clear that the second return behaves quite differently from the first.
<br>It gets more difficult if the code in the block cq closure gets very large.
<br>Also, I would expect that beginners would have problems understanding this (subtile but important) difference.
<br>
<br>Regards,
<br>Rien
<br>
<br>Site: http://balancingrock.nl
<br>Blog: http://swiftrien.blogspot.com
<br>Github: http://github.com/Balancingrock
<br>Project: http://swiftfire.nl
<br>
<br>
<br>
<br>
<br>
<br>> On 15 Mar 2017, at 12:19, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:
<br>>
<br>> 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?
<br>>
<br>> 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
<br>>
<br>> 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>>
<br>> Let me know if I understood your gist now.
<br>>
<br>> if someFunction { …; return } // someFunction cannot have a trailing closure here!
<br>>
<br>>
<br>>
<br>>
<br>> --
<br>> Adrian Zubarev
<br>> Sent with Airmail
<br>>
<br>> Am 15. März 2017 um 12:08:19, Rien (rien@balancingrock.nl) schrieb:
<br>>
<br>>> If I wrote this:
<br>>>
<br>>> if serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); return }
<br>>>
<br>>> then the meaning of return would have been different.
<br>>>
<br>>> 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>>>
<br>>> 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>>>
<br>>> Regards,
<br>>> Rien
<br>>>
<br>>> Site: http://balancingrock.nl
<br>>> Blog: http://swiftrien.blogspot.com
<br>>> Github: http://github.com/Balancingrock
<br>>> Project: http://swiftfire.nl
<br>>>
<br>>>
<br>>>
<br>>>
<br>>>
<br>>> > On 15 Mar 2017, at 12:00, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:
<br>>> >
<br>>> > 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>>> >
<br>>> > You can simply write this if you wanted to:
<br>>> >
<br>>> > myFucntion(someLabel: abc, closureLabel: { …; return })
<br>>> >
<br>>> > Parentheses are indicating that your closure is immediately invoked.
<br>>> >
<br>>> > let someInt = { return 42 }()
<br>>> > print(someInt)
<br>>> >
<br>>> > let someClosureWhichReturnsAnInt = { return 42 } // You can reuse the closure
<br>>> > print(someClosureWhichReturnsAnInt()) // Invocation happens now here
<br>>> >
<br>>> > 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>>> >
<br>>> >
<br>>> >
<br>>> >
<br>>> > --
<br>>> > Adrian Zubarev
<br>>> > Sent with Airmail
<br>>> >
<br>>> > Am 15. März 2017 um 11:35:39, Rien via swift-evolution (swift-evolution@swift.org) schrieb:
<br>>> >
<br>>> >> What does the following code fragment do?
<br>>> >>
<br>>> >> serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); return }
<br>>> >>
<br>>> >> The only possible answer is: I don’t know.
<br>>> >>
<br>>> >> The problem is finding out what the “return” statement will do.
<br>>> >>
<br>>> >> 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>>> >>
<br>>> >> This could be disambiguated by using the same syntax as for lazy variables:
<br>>> >>
<br>>> >> serverCert.write(to: serverCertificateUrl) { showErrorInKeyWindow(message: message); return }()
<br>>> >>
<br>>> >> Now it is clear that the return statement will only terminate the (trailing) closure.
<br>>> >>
<br>>> >> A question to the educators on the list: Is this a real problem?
<br>>> >>
<br>>> >> Personally, I dislike this situation, but I am also ambivalent towards the solution I just described.
<br>>> >>
<br>>> >> Regards,
<br>>> >> Rien
<br>>> >>
<br>>> >> Site: http://balancingrock.nl
<br>>> >> Blog: http://swiftrien.blogspot.com
<br>>> >> Github: http://github.com/Balancingrock
<br>>> >> Project: http://swiftfire.nl
<br>>> >>
<br>>> >>
<br>>> >>
<br>>> >>
<br>>> >>
<br>>> >> _______________________________________________
<br>>> >> swift-evolution mailing list
<br>>> >> swift-evolution@swift.org
<br>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
<br>>>
<br>
<br></div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>