[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?
-Andy
>> 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