<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 Dec 18, 2015, at 6:18 PM, Janosch Hildebrand via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I like `UnsafeReference` as the new name of the type and I think the basic API is clearer than with `Unmanaged`.</div><div class="">The initializers are much better than the static methods and `take(Un)RetainedValue()` were certainly less than ideal method names.</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 18 Dec 2015, at 02:37, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div></blockquote><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><ul class="MailOutline"><li class="">The name of the <font face="Menlo" class="">release()</font> method has been contentious.</li></ul></div></div></blockquote><div class=""><br class=""></div><div class="">This is a hard one. I don't particularly like `release()` for this but I can't really think of anything better either.</div><div class="">I think it's descriptive which is good but it will take some getting used to as the "consuming" method although the documentation is pretty clear about the semantics which is helpful.</div><div class=""><br class=""></div><div class="">The `.releaseAndReturnObject` proposed by TJ feels a bit clearer but is also a lot more verbose.</div><div class="">Also I don't think it would make anything clearer if I didn't already know about the manual memory management terminology.</div><div class="">And something along these lines would also be bit more awkward to use if the return values were then discarded, although the proposed `manuallyRelease()` would take care of that...</div></div></div></div></blockquote><div><br class=""></div>I don't see any point in having "manuallyRelease()" if we already have "release()"; they'd do the same thing if you dropped the return value.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><ul class="MailOutline"><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></ul></div></div></blockquote><div class=""><br class=""></div><div class="">Coming from Objective-C I find it makes sense. I also don't think the terminology is a big issue here. If you know the concepts you're probably able to map them to these terms and the documentation seems helpful in that case.</div><div class=""><br class=""></div><div class="">If, on the other hand, you are not familiar with manual reference counting concepts I doubt this will be very helpful.</div><div class="">But I don't think that can be solved with different terminology but instead requires more extensive documentation.</div><div class="">However I don't think the documentation for `UnsafeReference` is the place to try to explain the whole concept and this is more of a topic for `The Swift Programming Language` or a separate (advanced) tutorial or guide.</div><div class=""><br class=""></div><div class="">I like that the documentation tries to lay out a clear path to follow if you just want to get an object out of some un-annotated CF API but I can't really personally judge how well that works for a novice.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">One other approach to terminology that comes to mind would be to focus more on the <b class="">transfer of ownership</b> <b class="">into </b>ARC as opposed to <b class="">out of</b> MRC.</div><div class="">Personally I often reason in that direction when thinking about the topic but I can't see a way in which it would be helpful for the documentation or method names...</div></div></div></div></blockquote><div><br class=""></div>Yeah, doesn't give me any ideas for names, unfortunately.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><ul class="MailOutline"><li class="">We want to know whether the usage pattern recommended above works for you.</li></ul></div></div></blockquote><div class=""><br class=""></div><div class="">For interacting with un-annotated CF APIs: Yes.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><ul class="MailOutline"><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></blockquote><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">On 18 Dec 2015, at 03:05, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</blockquote></div><blockquote type="cite" class=""><div class=""><div class="">- `Unmanaged` has also been promoted as a solution for people who need to do manual reference counting, for performance or other reasons, so I think we might want to keep the 'retain()' method. Conveniently enough, `release()`-ing and dropping the return value would have the net effect of decrementing the refcount by one, though the admonitions about the `UnsafeReference` become invalid after that point wouldn't hold if you're using `release()` purely for that effect, so maybe `manuallyRetain()`/`manuallyRelease()` would be more appropriate for manual refcounting applications.</div></div></blockquote><div class=""><br class=""></div>As Joe mentioned, `Unmanaged` has a use for manual ref counting beyond immediate transfer from un-annotated APIs. </div><div class=""><br class=""></div><div class="">I have used it for performance reasons myself (~ twice) and while I think it's a pretty small use case there isn't really any alternative.</div><div class="">If it would help I can also describe my use-cases in more detail.</div></div></div></blockquote><div><br class=""></div>Yes please!</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I don't think this use case even needs to be described in the documentation for `UnsafeReference` and it's fine if its use is very much discouraged.</div><div class=""><br class=""></div><div class="">Personally I prefer the proposed `manuallyRetain()`/`manuallyRelease()` over plain `retain()`/`release()` as it clearly separates the returning and more generally applicable `release()` from the MRC methods. `retain()` would probably also have to return the object which would interfere with the max safe usage pattern.</div></div></div></blockquote><div><br class=""></div>I don't understand your last sentence; care to clarify?</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On 18 Dec 2015, at 03:05, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">- The `bitPattern:` constructors should be between UnsafeReference and Unsafe[Mutable]Pointer<Void>, not COpaquePointer. Let COpaquePointer retire gracefully.</div></div></blockquote><div class=""><br class=""></div><div class="">Very much agreed.</div></div></div></div></blockquote></div><div class=""><br class=""></div>Please see my comment <a href="https://github.com/apple/swift-evolution/pull/44#issuecomment-165902471" class="">here</a><div class=""><br class=""></div><div class=""><div>Thanks again,</div><div class=""><br class=""></div><div class="">
-Dave<div class=""><br class=""></div><br class="Apple-interchange-newline">
</div>
<br class=""></div></body></html>