[swift-evolution] Open Issues Affecting Standard Library API Stability

[Harlan Haskins]

I’ve also seen unsafeAddressOf(_:) used when interfacing with C function pointers when the lifetime of an object is guaranteed. Many C APIs vend an API like:

void perform_action(void (*callback)(void *data), void *initial_data);

For which it is expected to use unsafeAddressOf on a class instance, like:

perform_action({ data in
  let _self = unsafeBitCast(data, to: MyClass.self)
  _self.foo()
}, data: unsafeAddressOf(self))

It’s unsafe and error-prone, sure, but that’s why we have `unsafe` in the name 😅 — I’ve had to use this to interface with libclang.

(For an existing example of this, see SwiftGtk: https://github.com/TomasLinhart/SwiftGtk/blob/master/Sources/Application.swift <https://github.com/TomasLinhart/SwiftGtk/blob/master/Sources/Application.swift>)

— Harlan

> On Jul 6, 2016, at 11:01 AM, Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Tue, Jul 5, 2016 at 10:50 PM, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> > Remove unsafeAddressOf. We are not aware of any real usecases for it. If there are any, it should be renamed to unsafeAddress(of:) to follow the guidelines.
> Obvious, unless someone comes up with use cases during the review period.
> 
> 
> 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/20160706/816b3670/attachment.html>