[swift-evolution] [Discussion] Cleaning up stdlib pointer and buffer routines (Open Issues Affecting Standard Library API Stability)
Charlie Monroe
charlie at charliemonroe.net
Wed Jul 6 08:51:44 CDT 2016
> * Remove unsafeAddressOf. "We are not aware of any real use cases for it. If there are any, it should be renamed to unsafeAddress(of:) to follow the guidelines." (https://bugs.swift.org/browse/SR-1957 <https://bugs.swift.org/browse/SR-1957> rdar://problem/18589289 <rdar://problem/18589289>)
I've mentioned on the bug report a few places in my code where I use the unsafeAddressOf - it can be used nicely to log the pointer to an instance - useful for debugging and is much shorter than
Unmanaged.passUnretained(x).toOpaque()
as Dmitri suggested - and clearer in a way - you are logging an address, you shouldn't have to deal with retain/unretained at all.
I'm definitely for keeping it around, the renaming seems good to me. Alternative to renaming it is to move this under Unmanaged:
Unmanaged.address(of: obj)
BTW Xcode 8 already sees it as renamed to unsafeAddress(of:).
> * Consider renaming or eliminating ManagedProtoBuffer. "The reason why ManagedProtoBuffer exists is to give the users an extra bit of type safety inside of the closure passed to ManagedBuffer.create(). This closure receives the ManagedBuffer instance and returns the initial value that is stored in the buffer (the header part of the buffer). We are passing the ManagedBuffer as ManagedProtoBuffer to prevent the closure from reading the uninitialized value property. Maybe this extra bit of safety is not worth the API surface complexity." (https://bugs.swift.org/browse/SR-1955 <https://bugs.swift.org/browse/SR-1955> rdar://problem/26012924 <rdar://problem/26012924> rdar://problem/27118532 <rdar://problem/27118532>.")
>
> * withUnsafePointer shouldn't take its argument as inout. (https://bugs.swift.org/browse/SR-1956 <https://bugs.swift.org/browse/SR-1956> rdar://problem/25019862 <rdar://problem/25019862>) Note: "Jordan has objections, see https://bugs.swift.org/browse/SR-1956 <https://bugs.swift.org/browse/SR-1956>"
>
> -- E
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160706/f3b070bf/attachment-0001.html>
More information about the swift-evolution
mailing list