<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 1, 2016, at 3:59 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Feb 1, 2016, at 1:43 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 1, 2016, at 3:25 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Feb 1, 2016, at 1:02 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:<br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">I’m glad to see an @autoclosure func in this thread. We will want to be able to use this feature with @autoclosure in addition to @noescape.</div><div class=""><br class=""></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">As far as exiting without calling the closure, I suggest `@noescape(once?)`. The `?` indicates the closure may or may not be called, but<span class="Apple-converted-space"> </span><b class="">will not</b> be called more than once.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I don’t see how this is useful. You wouldn’t be able to initialize a value with this semantic, so it isn’t any more powerful than @noescape on the caller side.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Right, you would not be able to use it for initialization.</div><div class=""><br class=""></div>It gives a guarantee that the closure will not be executed twice. This semantic guarantee could be useful, especially if the closure has side-effects. It adds the clarity of a guarantee to APIs where the zero-or-one-times semantic is implicit with @noescape alone.</div></div></div></blockquote><br class=""></div><div class="">Right, but unless the compiler is going to enforce it somehow, it doesn’t add any value above a comment. Particularly given that we want to keep the language simple where possible, I think that a comment would be perfectly fine for this. We don’t want to be in the business of providing a "documentation hook” in the language for every theoretical invariant someone might want to express.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I agree if the compiler isn’t going to enforce it. The value is in the guarantee. </div><div class=""><br class=""></div><div class="">Why wouldn’t the compiler enforce it in this case? Is it hard to implement? It doesn’t seem like it should be any harder than guaranteeing exactly once.</div></div></div></div></blockquote></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">You’re right, the caller could enforce this, so it does provide marginal value beyond a comment. I think the rest of my point stands though.</div></div></blockquote><div><br class=""></div><div>Sure, I think it’s a somewhat subjective judgement call. </div><div><br class=""></div><div>I prefer to get as many guarantees as possible from the compiler. In cases where the semantics are likely to be documented in a comment, assumed or implicit I would prefer to see them expressed directly in the language.</div><div><br class=""></div><div>I understand the case that it is simpler to leave it in a comment, I just have a different preference. </div><div><br class=""></div><div>There have been other topics where a similar tradeoff / judgement call is relevant, such as the `local` access control proposal. </div><div><br class=""></div><div>My sense so far is that Swift tries to strike a middle path, introducing annotations where the perceived benefit passes a test of being significant enough (such as the @noescape annotation and likely the once modifier). It seems like in *most* cases a mere semantic guarantee by the compiler isn’t considered to be benefit enough to pass that test - optimization potential and / or a new capability (such as the ability to initialize values). </div><div><br class=""></div><div>-Matthew</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">-Chris</div></div></blockquote></div><br class=""></body></html>