[swift-evolution] [Discussion] Cleaning up stdlib pointer and buffer routines (Open Issues Affecting Standard Library API Stability)

Charlie Monroe charlie at charliemonroe.net
Thu Jul 7 02:44:18 CDT 2016

As was pointed out to me in the bug report, the preferred way to get a pointer is to use


I see a few issues, though (aside from toOpaque() missing in Xcode 8b1, haven't installed b2 yet):

- it is quite a verbose way of something I consider should be trivial - getting an address of an object.
- it requires the caller to deal with retain cycle which I don't think should be explicit for getting an address of an object.

I'd personally leave it in the language as it feels similar to dynamicType(obj) and can be a nice-to-have debugging tool.

The most confusing part about unsafeAddress(of:) is implicit bridging which creates a new instance e.g. in case of String, in order to satisfy the AnyObject requirement. Fortunately, this will get eliminated by SE-0072 and Unmanaged suffered from the same issue, though it required you to specify either Unmanaged<NSString> or Unmanaged<AnyObject>.

> On Jul 6, 2016, at 8:03 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org> wrote:
> * 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 <>)
> Oops, I just responded to this on another thread. Pasting:
> It's minor, but I use unsafeAddressOf regularly for writing `description` methods:
>     var description: String {
>         return "<\(self.dynamicType): \(unsafeAddressOf(self))>{ more info here... }"
>     }
> I guess this would be covered by some generalized solution for format specifiers in string interpolations, but I gather that won't happen for quite a while... 
> _______________________________________________
> 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/20160707/312cddea/attachment.html>

More information about the swift-evolution mailing list