<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="" applecontenteditable="true"><div class="">[Proposal: <font face="-apple-system-body, Helvetica, arial, sans-serif" class=""><span style="background-color: rgb(255, 255, 255);" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md</a></span></font>]</div><div class=""><br class=""></div><div class="">I have severe concerns about these revisions because they make withoutActuallyEscaping harder to reason about.</div><div class=""><br class=""></div><div class="">+ - Programmers using ``withoutActuallyEscaping`` should take</div>+ care not to allow the result to be recursively invoked.<div class=""><br class=""></div><div class="">+[…] if they are certain that their code will<br class="">+not violate the NRR, use ``withoutActuallyEscaping`` to disable<br class="">+the NPCR check.<br class=""><br class=""><div class="">I think this constitutes a violation of the user model for withoutActuallyEscaping, because withoutActuallyEscaping hasn't historically meant withoutBeingReentrant. The proposal "should take care" is a very mild way of saying we're introducing a new rule under which the compiler can silently do something different than what you wrote (with no "unsafe" in sight). Similarly, using withoutActuallyEscaping to mean withoutActuallyViolatingExclusivity seems like it'll come back to haunt us, the kind of thing where people ask on Stack Overflow why the Swift people didn't design something that said what it did.</div><div class=""><br class=""></div><div class="">When I first brought this up on an Apple-internal list, John let me know that we could introduce checking for it. This helps assuage my concerns quite a bit, but I'm not sure how we would do so without modifying the original closure, and if we can modify the original closure I'm not sure we've saved anything over proper dynamic checking. John, can you clarify for the list <i class="">how</i> we might check for this? Like withoutActuallyEscaping, it doesn't have to be something we implement right away as long as we have the ability to do so without changing the ABI.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jordan</div><div class=""><br class=""></div><div class="">P.S. Devin and I had previously discussed an additional example that does not seem to be forbidden by these rules. Is that correct and will this program continue to print "2 2"?</div><div class=""><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">func invoke(_ callback: /*nonescaping*/ () -> Void) {</div></div><div class=""><div class=""> callback()</div></div><div class=""><div class="">}</div></div><div class=""><div class="">class Foo {</div></div><div class=""><div class=""> var op: () -> Void = {}</div></div><div class=""><div class=""> var prop = 0</div></div><div class=""><div class=""> func test() {</div></div><div class=""><div class=""> var x = 0</div></div><div class=""><div class=""> self.op = { x = 1; self.prop = 1 }</div></div><div class=""><div class=""> invoke { self.op(); x += 1; self.prop += 1 }</div></div><div class=""><div class=""> print(x, self.prop)</div></div><div class=""><div class=""> }</div></div><div class=""><div class="">}</div></div><div class=""><div class="">Foo().test()</div></div></blockquote><div class=""><div class=""><br class=""></div></div></body></html>