<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 class="">Hi Everybody,</div><div class=""><br class=""></div><div class="">We’ve been working on a rewrite of the Unmanaged<T> component, and are soliciting comments. First, a little background:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class=""><a href="https://developer.apple.com/library/ios/documentation/Swift/Conceptual/BuildingCocoaApps/WorkingWithCocoaDataTypes.html#//apple_ref/doc/uid/TP40014216-CH6-ID79" class="">Unmanaged</a> is primarily used as a return type from imported CoreFoundation functions that haven’t been annotated with reference-counting semantic information</li><li class="">A secondary known use-case is as a vehicle for creating a COpaquePointer containing a reference’s bits, e.g. for when you need to pass a reference through C APIs that use “void*” as a universal “give me some info and I’ll give it back to your callback” mechanism.</li></ul><div class=""><br class=""></div><ul class="MailOutline"><li class="">We saw several problems with Unmanaged that we wanted to fix:</li><ul class=""><li class="">It was poorly-named (the reference is managed by <i class="">somebody</i>, we just aren't representing that management in the type system).</li><li class="">Its interface was much broader than it needs to be to cover the use-cases</li><li class="">The purpose of many of its APIs was unclear</li><li class="">Its documentation was vague and hard to understand.</li><li class="">It didn’t establish a maximally-safe usage pattern for handling the results of un-annotated CoreFoundation functions.</li></ul></ul></div><div class=""><br class=""></div><div class="">The code for the proposed replacement, called UnsafeReference, is <a href="https://github.com/dabrahams/swift/blob/6eb86b48d150342709da3f3be9c738df23382866/stdlib/public/core/UnsafeReference.swift" class="">here</a>, and a commit that updates Swift to use it is <a href="https://github.com/dabrahams/swift/commit/6eb86b48d150342709da3f3be9c738df23382866" class="">here</a>. </div><div class=""><br class=""></div><div class=""><font size="5" class="">Maximally Safe Usage</font></div><div class=""><br class=""></div><div class="">The recommended usage pattern for handling an <font face="Menlo" class="">UnsafeReference<T></font> returned by a function <font face="Menlo" class="">CF<i class="">Something</i></font> is to always use the <font face="Menlo" class="">T</font> instance produced by one of the forms:</div><div class=""><br class=""></div><div class=""> <font face="Menlo" class="">CF<i class="">Something</i>(<i class="">arguments…</i>).release() // when the result is returned at +1</font></div><div class=""><br class=""></div><div class="">or</div><div class=""><br class=""></div><div class=""><div class=""> <font face="Menlo" class="">CF<i class="">Something</i>(<i class="">arguments…</i>).object // when the result is returned at +0</font></div></div><div class=""><br class=""></div><div class="">In other words, turn the <span style="font-family: Menlo;" class="">UnsafeReference<T></span> into a safe <span style="font-family: Menlo;" class="">T</span> as quickly as possible, and never store the <span style="font-family: Menlo;" class="">UnsafeReference<T></span> in a variable so that it can’t be (mis)used thereafter.</div><div class=""><br class=""></div><div class=""><div class=""><font size="5" class="">Points of Discussion</font></div></div><div class=""><br class=""></div><div class="">We’re interested in any feedback you might have, but there are a few points we’d especially like to address:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">The name of the <font face="Menlo" class="">release()</font> method has been contentious.</li><ul class=""><li class="">👍: Documentation—or naming conventions such as the “<a href="https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html" class="">create rule</a>”—normally says something like “you are responsible for releasing the result” in those cases where <font face="Menlo" class="">release()</font> must be called, so there’s a very direct way to know which variant of the recommended usage pattern to employ.</li><li class="">👎: Some people who are very familiar with existing manual retain/release programming find the recommended usage pattern really counter-intuitive because they're “using something after calling release on it,” which one never does in Objective-C.</li><li class="">The alternative names we’ve been able to think of so far are verbose, clumsy, and don’t match up with anything in the documentation of the called function, so this seems like a really hard naming problem. Better ideas from the community would be most welcome here.</li></ul><li class="">We’re not sure about the <a href="https://github.com/dabrahams/swift/blob/6eb86b48d150342709da3f3be9c738df23382866/stdlib/public/core/UnsafeReference.swift#L27" class="">terminology</a> (Unretained/Retained/Released) used to precisely describe the semantics of <font face="Menlo" class="">UnsafeReference</font>. We’d like to know if these terms make sense to you or whether you have better ideas.</li><li class="">We want to know whether the usage pattern recommended above works for you.</li><li class="">We want to know if the API is sufficiently broad or if there are things you currently get—and need—from <font face="Menlo" class="">Unmanaged</font> that we’ve left out.</li></ul></div><div class=""><br class=""></div><div class="">Thanks in advance,</div><div class=""><br class=""></div><div class=""><div class="">
-Dave<div class=""><br class=""></div><br class="Apple-interchange-newline">
</div>
<br class=""></div></body></html>