> On Apr 29, 2016, at 5:10 PM, Jordan Rose <jordan_r...@apple.com> wrote: > >> >> On Apr 28, 2016, at 17:22, Andrew Trick via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Apr 28, 2016, at 11:10 AM, Chris Lattner <clatt...@apple.com >>> <mailto:clatt...@apple.com>> wrote: >>> >>> Hello Swift community, >>> >>> The review of "SE-0017: Change Unmanaged to use UnsafePointer" begins now >>> and runs through May 3. The proposal is available here: >>> >>> >>> https://github.com/apple/swift-evolution/blob/master/proposals/0017-convert-unmanaged-to-use-unsafepointer.md >>> >>> <https://github.com/apple/swift-evolution/blob/master/proposals/0017-convert-unmanaged-to-use-unsafepointer.md> >> >> >> I have some concerns, but let me just suggest a simple alternative and see >> what people think... >> >> - Leave the existing from/toOpaque API until we can come up with a better >> plan for moving away from OpaquePointer. >> >> - Add initializers to avoid boilerplate, but only for "safe" variants of the >> cast: >> >> extension Unmanaged { >> @_transparent >> public init(_ from : UnsafePointer<Instance>) >> >> @_transparent >> public init?(_ from : UnsafePointer<Instance>?) >> } >> >> extension UnsafeMutablePointer where Pointee : AnyObject { >> @_transparent >> public init(_ from : Unmanaged<Pointee>) >> >> @_transparent >> public init?(_ from : Unmanaged<Pointee>?) >> } > > This isn’t correct; an UnsafeMutablePointer<Foo> is a pointer to a reference > to Foo. Unmanaged<Foo> is a wrapper around ‘unowned Foo’, i.e. it’s just the > reference. > > >> >> - This doesn't solve the stated problem of passing unmanaged pointers to >> 'void*' imports. Is that really an issue? I believe the correct fix is to >> stop importing 'void*' as UnsafePointer<Void>. We should have a nominally >> distinct "opaque" pointer type, 'void*' should be imported as that type, and >> casting from any UnsafePointer to the opaque pointer type should be inferred >> and implicit for function arguments. I can send a proposal for eliminating >> UnsafePointer<Void> next week, but the scope of that proposal will be much >> broader. > > This is one of the few major use cases for Unmanaged: passing objects through > C context pointers. If the type of a ‘void *’ pointer changes, then this > proposal should use that type. > > (The other supported uses of Unmanaged are interacting with existing CF APIs > that haven’t been audited, and dealing with fields of structs with class > type, neither of which use fromOpaque/toOpaque. That last actually isn’t > implemented correctly at the moment; we’re assuming those are all strong > references, which they aren’t.)
Thanks. Now I understand the purpose of this proposal. My concern was that UnsafePointer<Void> is probably not the right type for opaque pointers. I didn’t want users to begin rewriting COpaquePointer APIs with UnsafePointer<Void>, then force them to rewrite the same calls again back to some other opaque pointer type once we decide what that should be. I was hoping to sidestep my concerns and meet the goal of reduced syntax, but my suggestion was nonsense. I can start a separate thread next week on replacing UnsafePointer<Void> and see where that goes. This proposal is probably fine as-is, but there might be less impact for users if we change the imported void* type first. -Andy
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
