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

Jacob Bandes-Storch jtbandes at gmail.com
Tue Dec 8 18:03:01 CST 2015


Thanks, Jordan. I'll write one up tonight.

Should it use UnsafePointer or UnsafeMutablePointer?  I've seen that C APIs
frequently get imported as UnsafeMutablePointer, when it doesn't
necessarily match the semantics of the API. Is that just the default?

Jacob

On Tue, Dec 8, 2015 at 3:53 PM, Jordan Rose <jordan_rose at apple.com> wrote:

>
> On Dec 8, 2015, at 10:42, Joe Groff via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> 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> 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!
>
> Jordan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151208/8da6d3f7/attachment.html>


More information about the swift-evolution mailing list