[swift-evolution] RFC: Proposed rewrite of Unmanaged<T>

[Dave Abrahams]

Brent, thanks for working through this with me…

> On Dec 19, 2015, at 2:02 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>>>> 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.
>>> 
>>> I wonder if, instead of talking about retained/unretained, we should talk about whether the call “created" or “retrieved" the object it’s returning. If it created it, the object is +1; if it retrieved it, the object is +0.
>> 
>> I think I’d need more detail in order to evaluate the idea.  Are you suggesting changing the way some CF functions are documented?  Some concrete examples would certainly help.
> 
> CFAttributedString has actually been audited, but pretend it hasn't been...
> 
> 	let attributedString = CFAttributedStringCreate(nil, anotherString,nil).takeCreatedObject()
> 	let str = CFAttributedStringGetString(attributedString).takeRetrievedObject()
> 
> I'm not a huge fan of the "take" here,

Then why did you use it, if you don't mind my asking?  What is it supposed to mean in this context?

> 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.

Why is that better?

And how does "Retrieved" map onto "Get"?

Seems to me that if you know what the "Create Rule" is, you know it says "you're responsible for releasing the result."  If you know a name contains "Create", you already have a good clue that the "Create Rule" applies.  Isn't it the users of the functions that don't contain "Create" or "Get" in their names that need the most help?

-Dave