<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><blockquote type="cite" class="">On Dec 19, 2015, at 2:59 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">CFAttributedString has actually been audited, but pretend it hasn't been...<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let attributedString = CFAttributedStringCreate(nil, anotherString,nil).takeCreatedObject()<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let str = CFAttributedStringGetString(attributedString).takeRetrievedObject()<br class=""><br class="">I'm not a huge fan of the "take" here,<br class=""></blockquote><br class="">Then why did you use it, if you don't mind my asking? What is it supposed to mean in this context?<br class=""></blockquote><br class="">I suppose I'm struggling with the fact that there's clearly an action taking place here (at least in the created case), and yet merely saying `createdObject()` or `retrievedObject()` doesn't imply that. Those operations sound idempotent, but they're not.<br class=""></blockquote><div class=""><br class=""></div>But you applied "take" to both of them? One of them is idempotent while the other is not.<div class=""><br class=""><blockquote type="cite" class="">(I kind of want to suggest that retrieving an object through these calls should destroy the reference so it can't be used again, but I don't think that fits with Swift's mutation model without turning `Unmanaged`/`UnsafeReference` into a reference type and adding lots of overhead.)<br class=""></blockquote><div class=""><br class=""></div>Yes, there's no way to reconcile that with the safety offered by the recommended usage patterns, since you can't mutate an rvalue.</div><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">but I think this general strategy of trying to say whether the Create Rule or the Get Rule applies is better than trying to make people understand when they should use "released" or not.<br class=""></blockquote><br class="">Why is that better?<br class=""></blockquote><br class="">Mainly, because simply saying "release" or "released" is a bit ambiguous to me.Are you saying it *has been* released, or are you saying it *needs to be* released?</blockquote><div class=""><br class=""></div><div class="">But nobody proposed "released" as a method name. In what way is "release" ambiguous? It's an imperative verb.<br class=""></div><br class=""><blockquote type="cite" class="">I have the same problem with the current `takeRetainedValue()`/`takeUnretainedValue()` calls—I'm never sure which one I'm supposed to use. I'm hoping that, by stepping up a level and describing the semantic you want rather than the operation needed to achieve that semantic, this confusion can be cleared up.</blockquote><blockquote type="cite" class=""><br class="">I also like that this creates a matched pair of methods. Because they look sort of like each other, it's easier to understand that you should call one or the other, and to remember them.<br class=""></blockquote><div class=""><br class=""></div>The similarity of those names seems to me like a <u class="">weakness</u> of the current Unmanaged design: to me they are so similar it's hard to understand which one to call.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">And how does "Retrieved" map onto "Get"?<br class=""></blockquote><br class="">Not all that cleanly, I admit. "Gotten" would be better, but "get" is an irregular verb and I'm a little concerned about programmers who have English as a second language. (Plus, I subjectively think it's kind of ugly.)<br class=""><br class="">(One possibility would be to have a single call with an enum parameter, like `bridge(.Create)` and `bridge(.Get)`. This would let you use the regular form of the verb.)<br class=""></blockquote><div class=""><br class=""></div>There's no "bridging" going on here, though. This is simply "turn this unsafe thing into a safe thing in one of two ways"</div><div class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">Isn't it the users of the functions that don't contain "Create" or "Get" in their names that need the most help?<br class=""></blockquote><br class="">I think of it more as "treat this like a Create function" or "treat this like a Get function".<br class=""></blockquote><div class=""><br class=""></div>So far, my personal assessment of this direction is that it's no better than what I proposed, and has several weaknesses I'd like to avoid. In fact, it seems very similar to and roughly as understandable as the current Unmanaged design. I recognize that this is a highly subjective judgement, so if others disagree with me, I'd really like to hear about it. This is a tough design space and ultimately, what resonates best with the community is likely to be the best choice.</div><div class=""><br class=""></div><div class="">Thanks again,</div><div class=""><br class=""><div class="">-Dave<br class=""><br class=""><br class=""></div><br class=""></div></body></html>