[swift-evolution] Unmanaged, and COpaquePointer vs. Unsafe(Mutable)Pointer
jgroff at apple.com
Tue Dec 8 12:42:20 CST 2015
> On Dec 8, 2015, at 10:32 AM, Jacob Bandes-Storch <jtbandes at gmail.com> wrote:
> On Tue, Dec 8, 2015 at 9:42 AM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
> COpaquePointer is IMO a vestige that should be eliminated completely. We'd ultimately like to import opaque C structs as distinct, non-constructible types in Swift, so that they can still be well-typed UnsafePointer<OpaqueThing> types in Swift.
> That would be nice. But there is still the "context pointer" use case, where conversions to/from UnsafePointer<Void> are needed. Would it make sense for the Unmanaged type to deal in UnsafePointer<Void>, rather than COpaquePointer?
I think so, yeah.
> On Tue, Dec 8, 2015 at 9:37 AM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>> - Add implicit conversion from COpaquePointer to Unsafe(Mutable)Pointer<Void>, and/or vice versa.
>> - Even better, add implicit conversion from Unmanaged<T> to COpaquePointer or UnsafePointer<Void>, behaving the way toOpaque() currently does. Also, replace Unmanaged.fromOpaque() with an initializer Unmanaged(_: UnsafePointer<Void>).
> We try very hard to avoid adding new implicit conversions.
> My impression is that Unmanaged is pretty much only used for cases like this. It seems a bit redundant given that UnsafePointer exists, and converting between them is tedious as a user. Would it make sense to move the passUnretained/takeRetainedValue/etc. functions onto UnsafePointer?
It possibly makes sense for the methods to exist on both Unmanaged and UnsafePointer<Void>, since it's common to cross over from the managed to unmanaged world both ways.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution