<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=""><div><blockquote type="cite" class=""><div class="">On Mar 14, 2016, at 8:00 AM, Arnold Schwaighofer <<a href="mailto:aschwaighofer@apple.com" class="">aschwaighofer@apple.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I would like to propose adding an additional method to the standard library’s ‘Unmanaged’ wrapper to mark values as having a guaranteed lifetime by another reference to it.</div><div class=""><br class=""></div><div class="">Currently, there is no way to opt out of ARC even if we know the lifetime of a value is guaranteed by another reference to it. We can pass around values in the wrapper without incurring reference counting but as soon as we take the instance out of the wrapper we will incur reference counting.</div><div class=""><br class=""></div><div class=""><pre style="color: rgb(51, 51, 51); box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; padding: 16px; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-wrap: normal; word-break: normal;" class=""><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">func</span> <span class="pl-en" style="box-sizing: border-box; color: rgb(121, 93, 163);">doSomething</span>(u: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Unmanaged</span><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);"><</span>Owned<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">></span>) {
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// Incurs refcount increment before the call and decrement after for self.</span>
u<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">.</span><span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">takeUnretainedValue</span>()<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">.</span>doSomeWork()</pre><div class=""><br class=""></div></div><div class="">The addition of this API will allow selectively disabling ARC for the scope of the lifetime of the value returned by this API call.</div></div></div></blockquote><div><br class=""></div>Calling this method makes a semantic guarantee that the returned reference is being kept alive somehow for a certain period of time. So, the obvious questions here are:</div><div><br class=""></div><div>1. What are the bounds of that period of time?</div><div>2. How can the user actually satisfy this guarantee?</div><div>3. What happens if they’re wrong?</div><div><br class=""></div><div><div>#1 is totally unclear in your proposal. Usually we do this sort of scoping thing with a callback, rather than a property, for exactly the reason that it lets us naturally bound the extent of the guarantee. The library’s implementation of that function would then use some builtin functions to bound how long the guarantee lasts. If we decide that that’s too awkward to actually use, we could burn this into the language as a custom result convention and invent some language rules for the guaranteed extents of such a result based on how the expression is used; that would permit more APIs to opt in to a +0 guaranteed result, but the language rules would probably be pretty ad hoc. </div><div><br class=""></div><div>#2 is also uncertain. In ObjC ARC, we have a concept of an “object with precise lifetime semantics”. (Here, “object” is used in the C/C++ sense of “variable”, not the reference-type-OO sense of “class instance”.) Globals always have precise lifetime semantics, locals can opt in with an attribute, and members depend on their container. So one possible answer is to say that the value must be precisely referenced somehow, perhaps by the system. That does require doing some leg work in the proposal (to import the concept of precise lifetime), the language (to allow locals to be made precise), and and the compiler/optimizer (to honor precise guarantees).</div><div><br class=""></div></div><div>It sounds like the only reasonable answer for #3 is “it’s undefined behavior”. That argues for putting “unsafe” somewhere in the name, although perhaps that’s already covered by the proposal to rename Unmanaged to UnsafeReference.</div><div><br class=""></div><div>John.</div></body></html>