Unmanaged, and COpaquePointer vs. Unsafe(Mutable)Pointer

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

···

On Dec 8, 2015, at 12:26 AM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:

One hopes to avoid COpaquePointer and Unsafe(Mutable)Pointer, but in practice I've had occasion to use them a few times.

Things that are nice:

- Unmanaged.passUnretained/takeRetained/etc. which make memory management semantics explicit.

Things I've been frustrated by:

- An API takes UnsafeMutablePointer<Void>, but Unmanaged.toOpaque() returns a COpaquePointer.

- An API gives me UnsafeMutablePointer<Void>, but Unmanaged.fromOpaque() takes a COpaquePointer.

In practice, I end up with monstrosities like:

Unmanaged.passRetained(CFCopyDescription(Unmanaged<AnyObject>.fromOpaque(COpaquePointer($0)).takeUnretainedValue()))

I think a few things could help:

- Phase out COpaquePointer in favor of UnsafePointer<Void> (is this already happening?)

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

What are others' experiences? Would it be feasible/favorable to have some of these conversions?

Jacob Bandes-Storch
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution