<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="">If the casts are always in one direction, can you make one protocol refine another?<div class=""><br class=""></div><div class="">Also note that @objc protocols are self-conforming as long as they don’t contain initializers or static methods, but I’m not sure if that helps.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 4, 2016, at 4:29 PM, Alexis 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">The swift standard library has this nasty little pattern/problem in it:<div class=""><br class=""></div><div class="">The types in the core library want to know about several types defined in foundation: NSString, NSArray, NSDictionary, etc. But core is <i class="">imported</i> by Foundation, so it can’t (circular references between modules). Thankfully, everything in ObjC is pretty opaquely defined and uniform, and Swift knows how to hook into that uniform layout. So the core library defines <i class="">Shadow Protocols</i> which provide whatever subset of that type’s API is considered interesting. These protocols are then used in place of the ObjC types. There’s also some magic compiler hooks so core lib types can subclass those foundation types.</div><div class=""><br class=""></div><div class="">However there’s sometimes <i class="">two</i> Shadow Protocols: one that defines the APIs the stdlib should provide (_NSFooCore), and one that extends that with extra APIs the stdlib wants to consume (_NSFoo). This leads to an awkward situation: as far as the runtime is concerned, the stdlib’s _NSFooCores don’t conform to _NSFoo! We know they do because it’s all just a big lie to hook into ObjC message passing with a bit of type safety, but the runtime doesn’t. So if you try to do a safe type cast, it will fail. This leads to a situation where we sprinkle code with unsafeBitCast’s to _NSFoo which is a massive refactoring hazard.</div><div class=""><br class=""></div><div class="">For instance, there was a struct-containing-a-class that was being cast to _NSFoo in HashedCollections. This happened to work (but was probably still a violation of strict aliasing?) because the struct’s only field was the class. However the struct was later changed to a class, which silently made the cast completely incorrect, banishing the real _NSFoo to the shadow (protocol) realm.</div><div class=""><br class=""></div><div class="">Can we do anything better here? Note that there’s a few places where we also cast an AnyObject into an _NSFoo, but there’s some chance this is all legacy junk that can be updated to at least use _NSFooCore, if not _NSFoo itself.</div></div>_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></div></blockquote></div><br class=""></div></body></html>