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

[Dave Abrahams]

> On Dec 8, 2015, at 3:53 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Dec 8, 2015, at 10:42, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On Dec 8, 2015, at 10:32 AM, Jacob Bandes-Storch <jtbandes at gmail.com <mailto: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.
>>> 
>>> -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?
>> 
>> I think so, yeah.
> 
> Confirming that this is the direction we should go. We can do this independent of any changes to COpaquePointer, since you'll (almost) never want to pass a class reference through an opaque struct pointer. Feel free to make this part a formal proposal!

I’m not sure we want to retire the idea of a separate opaque pointer type As noted here <https://github.com/apple/swift-evolution/pull/44#issuecomment-165902471>, pointers to Void and incomplete types are not in any sense “unsafe” (once you restrict the interface as appropriate for incomplete types), and so maybe we want OpaquePointer<T>.

-Dave



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/c0318e9b/attachment.html>