[swift-evolution] [swift-evolution-announce] [Review] SE-0017: Change Unmanaged to use UnsafePointer
Jordan Rose
jordan_rose at apple.com
Fri Apr 29 19:10:37 CDT 2016
> On Apr 28, 2016, at 17:22, Andrew Trick via swift-evolution <swift-evolution at swift.org> wrote:
>
>
>> On Apr 28, 2016, at 11:10 AM, Chris Lattner <clattner at 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
>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160429/8d82c6bc/attachment.html>
More information about the swift-evolution
mailing list