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
> <[email protected]> wrote:
>
> On Tue, Jul 5, 2016 at 10:50 PM, Dmitri Gribenko via swift-evolution
> <[email protected] <mailto:[email protected]>> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
