> On Apr 28, 2016, at 17:22, Andrew Trick via swift-evolution > <[email protected]> wrote: > > >> On Apr 28, 2016, at 11:10 AM, Chris Lattner <[email protected]> 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 > > > 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.) Jordan
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
