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

[Greg Parker]

> On Dec 17, 2015, at 5:37 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 	• The name of the release() method has been contentious.
> 		• 👍: Documentation—or naming conventions such as the “create rule”—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.

For inspiration, the Objective-C ARC analogues to UnsafeReference.release() are:
    safeReference = (__bridge_transfer id)unsafeReference;
    // foreign retain count is "transferred" to ARC's control

    safeReference = CFBridgingRelease(unsafeReference);
    // conceptually balances CFCreate…() or CFRetain() even though it may or may not perform a release.

The two operations behave identically. Most people find that one or the other matches their mental model better. (Personally I find CFBridgingRelease() to be perfectly natural and I can never remember which way the __bridge_* casts work.)


-- 
Greg Parker     gparker at apple.com     Runtime Wrangler