> On Dec 8, 2015, at 3:53 PM, Jordan Rose via swift-evolution 
> <[email protected]> wrote:
> 
>> 
>> On Dec 8, 2015, at 10:42, Joe Groff via swift-evolution 
>> <[email protected] <mailto:[email protected]>> wrote:
>> 
>>> 
>>> On Dec 8, 2015, at 10:32 AM, Jacob Bandes-Storch <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> 
>>> On Tue, Dec 8, 2015 at 9:42 AM, Joe Groff <[email protected] 
>>> <mailto:[email protected]>> 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



_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to