And +1 for documentation. Do you have any guide about how dynamic casting actually works? It would perfectly fit there.<br><br>And if there is no public guide, I think it would be great to have one because as far as I see from the code, there are many different scenarios and different behaviors for each scenario, and implementations are implicitly affected by that.<br><br>I had to follow stack trace on crash, tried to find the method corresponding to the ObjC type case, find them in source code and compare :)<br><div class="gmail_quote"><div dir="ltr">On Wed, 8 Jun 2016 at 22:17, Yavuz Nuzumlalı &lt;<a href="mailto:manuyavuz@gmail.com">manuyavuz@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="white-space:pre-wrap">Hmm, interesting.<br><br>So, we can say that NSProxy class, which is the base structure for implementing proxy pattern, will not work for a Swift type, right? And I simply can&#39;t use proxy pattern if real object can be a Swift type.<br><br>In my use case, I have a framework, and I want to switch developer&#39;s some delegate object with my NSProxy standin, listen delegate method myself, then forward to the developer&#39;s original delegate object.<br><br>It was working without any issues for delegate objects which are Objective-C classes. But, it fails for Swift types because dynamic casting does not work anymore.<br><br>So, do you have any suggestions about how can I handle this interception functionality without NSProxy? <br><br>I don&#39;t want to do swizzling :)<br><br>Thanks for the explanations!</div><br><div class="gmail_quote"><div dir="ltr">On Wed, 8 Jun 2016 at 21:13, Jordan Rose &lt;<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jun 8, 2016, at 10:52, Joe Groff via swift-dev &lt;<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>&gt; wrote:</div><br><div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br>On Jun 8, 2016, at 12:44 AM, Yavuz Nuzumlalı via swift-dev &lt;<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>&gt; wrote:<br><br>Hi all,<br><br>swift_dynamicCastClassUnconditional and swift_dynamicCastObjCClassUnconditional methods behave differently while verifying casting.<br><br>swift_dynamicCastObjCClassUnconditional method calls -isKindOfClass: method before falling back to object_getClass function.<br><br>swift_dynamicCastClassUnconditional method calls swift_dynamicCastClass method which calls _swift_getClassOfAllocated method which calls directly object_getClass function.<br><br>This causes problems if underlying object is an NSProxy subclass.<br><br>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&#39;s class.<br><br>However, object_getClass function directly accesses to the metadata of the given object, so it returns NSProxy subclass.<br><br>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></blockquote><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">This is intentional, since NSProxy instances are generally expected to be standins for the proxied object. Important Cocoa idioms break down if the &quot;real&quot; class is exposed instead of the class a proxy pretends to be.</span></div></blockquote><br></div></div><div style="word-wrap:break-word"><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&#39;t work for a Swift type. (And by &quot;wouldn&#39;t work&quot; I mean &quot;would crash your program&quot;.) However, for an Objective-C type, all accesses Swift does will always go through the Objective-C runtime, so it&#39;s safe to use an Objective-C-style proxy, and indeed some Cocoa APIs expect this.</div><div><br></div><div>This is probably something we could stand to document more explicitly, but I&#39;m not sure where.</div></div><div style="word-wrap:break-word"><div><br></div><div>Jordan</div><br></div></blockquote></div></blockquote></div>