<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 17, 2015, at 7:32 PM, Félix Cloutier <<a href="mailto:felixcca@yahoo.ca" class="">felixcca@yahoo.ca</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="">If this can be used as any reference, I wrote some code to help interoperate with Python in C++.</div></div></blockquote><div><br class=""></div>BTDT; see <a href="http://boost.org/libs/python" class="">http://boost.org/libs/python</a> :-)</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="">The Python API inconsistently returns references with a +0 or +1 count. I use macros called TAKEREF (when the object is returned with a +1 count) and ADDREF (when it's returned with +0) to create smart wrappers. The wrapper will always decrement the reference count during destruction.<div class=""><br class=""></div><div class="">I find it unambiguous: you need to add a reference if you're going to take one away at destruction, so ADD; but if the object is returned with a +1 count, you can just TAKE the reference. It coincidentally does not borrow terminology from Objective-C's memory management system.</div></div></div></blockquote><div><br class=""></div>But it does tread on an area we’re trying very hard to clear up in Swift’s use of terminology: what does the word “take” mean? In fact the “take” problem was partly caused by the existing design of Unmanaged. Also, while unambiguous, it’s a very low-level description of what’s happening, that doesn’t much help the user reading the documentation of a CF function to answer the “which one do I use?” question unless s/he’s already experienced with how to map what it says in that docs onto the use of ADDREF/TAKEREF.</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=""><div class=""><blockquote type="cite" class=""><div class="">Le 17 déc. 2015 à 21:23:56, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: LucidaGrande; 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="">I think I see what you mean about parity. `.object` can be called multiple times, then? Why not make `release()` slightly more verbose since it should only be called once anyway? Something along the lines of `.releaseAndReturnObject` or … something slightly less verbose. <div class=""><br class=""></div><div class="">My main point of contention with `.release()` is that it has the *exact* same name as a method from the MRC strategy. Maybe this is a silly point, but this overlap could further complicate teaching how ARC works and in what ways it is based on MRC conventions. I am not of the opinion that ARC is fundamentally more difficult to understand than MRC, but I do believe that it takes a very particular kind of faith now that we don't get to manually write the retains and releases. This is completely worth it, in my opinion, but I want to avoid making it *more* confusing to explain what ARC doing at compile time. </div><div class=""><br class=""></div><div class="">TJ</div></div><div class="gmail_extra" style="font-family: LucidaGrande; 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 class="gmail_quote">On Thu, Dec 17, 2015 at 9:13 PM, Dave Abrahams<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:dabrahams@apple.com" target="_blank" class="">dabrahams@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class="">Thanks very much for the quick feedback TJ, </div><div class=""><br class=""></div><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Dec 17, 2015, at 5:52 PM, T.J. Usiyan <<a href="mailto:griotspeak@gmail.com" target="_blank" class="">griotspeak@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Hello Dave,<div class=""><br class=""></div><div class="">I like this change and think that it will help clarify the purpose of the type. As I was reading, the only concern that I had was the name. Could you please provide some of the names that you all have considered<span class="Apple-converted-space"> </span></div></div></div></blockquote><div class=""><br class=""></div></span>Honestly, I am sorry to say, we did that exercise almost a month ago and I don’t remember the ones we discussed.</div><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">so that we can avoid suggesting the same things? My suggestion is </div><div class=""><br class=""></div><div class=""><div style="font-size: 13px;" class=""> <font face="Menlo" class="">CF<i class="">Something</i>(<i class="">arguments…</i>).retainedObject() // when the result is returned at +1</font></div><div style="font-size: 13px;" class=""><br class=""></div><div style="font-size: 13px;" class="">or</div><div style="font-size: 13px;" class=""><br class=""></div><div style="font-size: 13px;" class=""> <font face="Menlo" class="">CF<i class="">Something</i>(<i class="">arguments…</i>).unretainedObject() // when the result is returned at +0</font></div></div><div style="font-size: 13px;" class=""><font face="Menlo" class=""><br class=""></font></div>on the premise that the important bit of information is whether or not the object is already retained. No matter what names are chosen, that is the data which determines which method to call. `retainedObject | unretainedObject`, `takeRetainedObject | takeUnretainedObject`, or `retained | unretained` all seem like viable options (that you have probably considered).</div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div></span>Some issues with these names:</div><div class=""><br class=""></div><div class=""><ul class=""><li class="">The <a href="https://swift.org/documentation/api-design-guidelines.html#be-grammatical" target="_blank" class="">“ed/ing” rule</a> makes these names suggest that the accessors are idempotent, but the first one must be called exactly once. That name should really be an active verb since it is state-changing.</li><li class="">“retainedObject” also suggests that it’s returning some underlying object after retaining it, which is almost the opposite of what that API does… and vice-versa for “unretainedObject"</li><li class="">Also, the object “has been retained” in all cases, or it would have been deallocated. The question is whether the object would leak if we fail to call release on it</li><li class="">Nothing in these names connect them to what the documentation says about the functions that return Unmanaged, so it’s hard to know which one to call</li><li class="">The second API is objectively safer than the first one (which causes undefined behavior when overused and only leaks when underused). The API I proposed makes it clear that they are not peers, where yours implies parity—though I am of two minds about the value of representing the lack of parity.</li></ul></div><div class=""><br class=""></div><div class="">You may legitimately argue that any of these concerns are unimportant, but those are the ones that come up for me.</div><div class=""><div class="h5"><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">TJ</div><div class=""><br class=""></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Dec 17, 2015 at 8:37 PM, Dave Abrahams via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" 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=""><li class=""><a href="https://developer.apple.com/library/ios/documentation/Swift/Conceptual/BuildingCocoaApps/WorkingWithCocoaDataTypes.html#//apple_ref/doc/uid/TP40014216-CH6-ID79" target="_blank" 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=""><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<span class="Apple-converted-space"> </span><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" target="_blank" class="">here</a>, and a commit that updates Swift to use it is <a href="https://github.com/dabrahams/swift/commit/6eb86b48d150342709da3f3be9c738df23382866" target="_blank" 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<span class="Apple-converted-space"> </span><font face="Menlo" class="">UnsafeReference<T></font><span class="Apple-converted-space"> </span>returned by a function<span class="Apple-converted-space"> </span><font face="Menlo" class="">CF<i class="">Something</i></font><span class="Apple-converted-space"> </span>is to always use the<span class="Apple-converted-space"> </span><font face="Menlo" class="">T</font><span class="Apple-converted-space"> </span>instance produced by one of the forms:</div><div class=""><br class=""></div><div class=""> <span class="Apple-converted-space"> </span><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=""> <span class="Apple-converted-space"> </span><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 class="Apple-converted-space"> </span><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=""><li class="">The name of the<span class="Apple-converted-space"> </span><font face="Menlo" class="">release()</font><span class="Apple-converted-space"> </span>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" target="_blank" class="">create rule</a>”—normally says something like “you are responsible for releasing the result” in those cases where<span class="Apple-converted-space"> </span><font face="Menlo" class="">release()</font><span class="Apple-converted-space"> </span>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" target="_blank" class="">terminology</a> (Unretained/Retained/Released) used to precisely describe the semantics of<span class="Apple-converted-space"> </span><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<span class="Apple-converted-space"> </span><font face="Menlo" class="">Unmanaged</font><span class="Apple-converted-space"> </span>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=""></div><br class=""></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=3FGfocPbgxkNkmje7djckg9Iw-2BGYY3X6RxJ1tkUXKCqykc-2FqvD6RA4Kk-2FqmXE0Z5aP9e7T8v6GNiR4gmT-2Bsb2uF-2F-2Bjnpc6za8Ziq0Ab54tqerszr6L6jONxR9lePuurF73ErW2FlVUsavvg650rR01qquqQ-2BPSKy9mQhdPVlp5R5P-2FYV5LfMSxcKV-2F2LQsjudDhAsZQswduZViik6Epfu8NUpbkQ-2B3ewHkCNsa-2FWTrM-3D" alt="" width="1" height="1" border="0" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""></div><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""><br class=""></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div><span class="HOEnZb"><font color="#888888" class=""><div class="">-Dave<div class=""><br class=""></div><br class=""></div><br class=""></font></span></div></blockquote></div><br class=""></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=iRI3beHTe3UxYAHTlV3lA38zIPfHMhyuRzgTmGKV6k7eqGFDJ3sfKl-2FbtlElIZ8xFFqMJSPRQzHaa-2BmWDjtohvzxiP7eTg33xI-2FR25Vy741YmutPxa9MAfyvl2wfKA2idbtwFJEPe13ymFaOgcJAtMjq-2FLuCBVC0Aa8N6xiOumf0aSN1aGShIm2T5x-2FT9p-2FrmvPRbOtXzAbzbt4mKobcYg-3D-3D" alt="" width="1" height="1" border="0" style="font-family: LucidaGrande; 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; height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""><span style="font-family: LucidaGrande; 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; float: none; display: inline !important;" class=""><span class="Apple-converted-space"> </span>_______________________________________________</span><br style="font-family: LucidaGrande; 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=""><span style="font-family: LucidaGrande; 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; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: LucidaGrande; 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=""><a href="mailto:swift-evolution@swift.org" style="font-family: LucidaGrande; 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="">swift-evolution@swift.org</a><br style="font-family: LucidaGrande; 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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: LucidaGrande; 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="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""><div class="">
-Dave<div class=""><br class=""></div><br class="Apple-interchange-newline">
</div>
<br class=""></body></html>