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

[T.J. Usiyan]

Hello Dave,

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 so that we
can avoid suggesting the same things? My suggestion is

    CF*Something*(*arguments…*).retainedObject() // when the result is
returned at +1

or

    CF*Something*(*arguments…*).unretainedObject()    // when the result is
returned at +0

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

TJ


On Thu, Dec 17, 2015 at 8:37 PM, Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

> Hi Everybody,
>
> We’ve been working on a rewrite of the Unmanaged<T> component, and are
> soliciting comments.  First, a little background:
>
>
>    - Unmanaged
>    <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/BuildingCocoaApps/WorkingWithCocoaDataTypes.html#//apple_ref/doc/uid/TP40014216-CH6-ID79> is
>    primarily used as a return type from imported CoreFoundation functions that
>    haven’t been annotated with reference-counting semantic information
>    - 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.
>
>
>
>    - We saw several problems with Unmanaged that we wanted to fix:
>       - It was poorly-named (the reference is managed by *somebody*, we
>       just aren't representing that management in the type system).
>       - Its interface was much broader than it needs to be to cover the
>       use-cases
>       - The purpose of many of its APIs was unclear
>       - Its documentation was vague and hard to understand.
>       - It didn’t establish a maximally-safe usage pattern for handling
>       the results of un-annotated CoreFoundation functions.
>
>
> The code for the proposed replacement, called UnsafeReference, is here
> <https://github.com/dabrahams/swift/blob/6eb86b48d150342709da3f3be9c738df23382866/stdlib/public/core/UnsafeReference.swift>,
> and a commit that updates Swift to use it is here
> <https://github.com/dabrahams/swift/commit/6eb86b48d150342709da3f3be9c738df23382866>
> .
>
> Maximally Safe Usage
>
> The recommended usage pattern for handling an UnsafeReference<T> returned
> by a function CF*Something* is to always use the T instance produced by
> one of the forms:
>
>     CF*Something*(*arguments…*).release() // when the result is returned
> at +1
>
> or
>
>     CF*Something*(*arguments…*).object    // when the result is returned
> at +0
>
> In other words, turn the UnsafeReference<T> into a safe T as quickly as
> possible, and never store the UnsafeReference<T> in a variable so that it
> can’t be (mis)used thereafter.
>
> Points of Discussion
>
> We’re interested in any feedback you might have, but there are a few
> points we’d especially like to address:
>
>
>    - The name of the release() method has been contentious.
>       - 👍: Documentation—or naming conventions such as the “create rule
>       <https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html>”—normally
>       says something like “you are responsible for releasing the result” in those
>       cases where release() must be called, so there’s a very direct way
>       to know which variant of the recommended usage pattern to employ.
>       - 👎: 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.
>       - 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.
>    - We’re not sure about the terminology
>    <https://github.com/dabrahams/swift/blob/6eb86b48d150342709da3f3be9c738df23382866/stdlib/public/core/UnsafeReference.swift#L27> (Unretained/Retained/Released) used
>    to precisely describe the semantics of UnsafeReference. We’d like to
>    know if these terms make sense to you or whether you have better ideas.
>    - We want to know whether the usage pattern recommended above works
>    for you.
>    - We want to know if the API is sufficiently broad or if there are
>    things you currently get—and need—from Unmanaged that we’ve left out.
>
>
> Thanks in advance,
>
> -Dave
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151217/903092ef/attachment.html>