[swift-evolution] Unmanaged, and COpaquePointer vs. Unsafe(Mutable)Pointer

[John McCall]

> On Dec 8, 2015, at 10:32 AM, Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org> 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.
> 
> -Joe
> 
> 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?
> 
> 
> 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.
> 
> John.
> 
> 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?

UnsafePointer<T> expresses an extra layer of indirection beyond what Unmanaged<T> does: in C terms, it is an Object** instead of an Object*.  I definitely don’t think we should collapse Unmanaged<T>s down to specifically UnsafePointer<Void> and lose the ability to express a type-safe unmanaged reference.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151208/175b5ada/attachment.html>