[swift-users] unsafeBitCast to Unimplemented Class

Andrew Trick atrick at apple.com
Mon Feb 6 22:22:22 CST 2017

> On Feb 5, 2017, at 9:01 AM, Dave Abrahams via swift-users <swift-users at swift.org> wrote:
> on Sat Feb 04 2017, Saagar Jha <saagar-AT-saagarjha.com <http://saagar-at-saagarjha.com/>> wrote:
>> Thanks–your not only did you method work, it had the side effect of
>> obviating the need for a Bridging Header. 
> Uh, wait: this doesn't add up.  If you needed a bridging header before,
> surely it was so that you could get a declaration for Bar?  If that's
> the case, you shouldn't be using this protocol hack.
>> One more thing: what happens if self isn’t a Bar (crash, I’m
>> guessing)? 
> No, it should just be using ObjC method dispatch (a.k.a. duck-typing)
> under the covers.  If you have a method with the right signature, things
> just work.

I don’t want to encourage reinterpreting a reference to `Bar` as a reference to `BarProtocol`, when `Bar` does not conform to the protocol according to the type system. Yes, it works for ObjC dispatch, and it’s done as an internal workaround in a couple places, but I would hesitate to say that’s it’s generally supported.

Is a missing declaration a use case that needs to be supported? Wouldn’t it be more proper to use selector based dispatch in those cases?


>> Is there a way to compare the type of self, other than using `is`
>> (which has the same issue as unsafeBitCast in that I don’t have the
>> declaration for it)?
> I think you might be able to use something like 
>  class_getName(type(of: x))

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170206/b1eee313/attachment.html>

More information about the swift-users mailing list