Regarding naming and clarity, my first impression is “yes, this is far better”.
After 1.5 years of doing Swift, I’m _still_ confused by `takeRetainedValue()` and `takeUnretainedValue()`. Perhaps it’s because I’ve been spared having to learn at a deep level how to do manual refcounting, and so I only occasionally have to interact with APIs that require this. Still, I always have to check the documentation, and re-read the descriptions of both carefully to make sure I’m not mixing up the two. Although `release()` probably isn’t perfect for reasons mentioned before (a hard naming problem indeed), I somehow find it easier to conceptualize it in my brain than `takeRetainedValue()`. And the asymmetry between `release()` and `value` definitely seems like a win to me — it really emphasizes that `value` doesn’t really “do” anything, you’re just using the underlying value. best, — Radek > On 18 Dec 2015, at 02:37, Dave Abrahams via swift-evolution > <swift-evolution@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 CFSomething is to always use the T instance produced by one of the > forms: > > CFSomething(arguments…).release() // when the result is returned at +1 > > or > > CFSomething(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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
