<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 8, 2016, at 10:52, Joe Groff via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">On Jun 8, 2016, at 12:44 AM, Yavuz Nuzumlalı via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class=""><br class="">Hi all,<br class=""><br class="">swift_dynamicCastClassUnconditional and swift_dynamicCastObjCClassUnconditional methods behave differently while verifying casting.<br class=""><br class="">swift_dynamicCastObjCClassUnconditional method calls -isKindOfClass: method before falling back to object_getClass function.<br class=""><br class="">swift_dynamicCastClassUnconditional method calls swift_dynamicCastClass method which calls _swift_getClassOfAllocated method which calls directly object_getClass function.<br class=""><br class="">This causes problems if underlying object is an NSProxy subclass.<br class=""><br class="">NSProxy class does not implement -isKindOfClass: method, so calls to this method are forwarded to the real object through -forwardInvocation: method, which causes -isKindOfClass: method to return answer according to the real object's class.<br class=""><br class="">However, object_getClass function directly accesses to the metadata of the given object, so it returns NSProxy subclass.<br class=""><br class="">I think this is a conflicting behavior, and I think swift_dynamicCastClassUnconditional method should also verify first using -isKindOfClass: method, in order to provide consistency.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">This is intentional, since NSProxy instances are generally expected to be standins for the proxied object. Important Cocoa idioms break down if the "real" class is exposed instead of the class a proxy pretends to be.</span></div></blockquote><br class=""></div><div>For a little more detail, Swift relies on a bit more information about layout of both instances and classes than Objective-C does, so an NSProxy stand-in wouldn't work for a Swift type. (And by "wouldn't work" I mean "would crash your program".) However, for an Objective-C type, all accesses Swift does will always go through the Objective-C runtime, so it's safe to use an Objective-C-style proxy, and indeed some Cocoa APIs expect this.</div><div><br class=""></div><div>This is probably something we could stand to document more explicitly, but I'm not sure where.</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>