[swift-dev] Casting shadow protocols

[Alexis]

> On Nov 4, 2016, at 11:55 PM, Dave Abrahams via swift-dev <swift-dev at swift.org> wrote:
> 
> 
> on Fri Nov 04 2016, Slava Pestov <swift-dev-AT-swift.org <http://swift-dev-at-swift.org/>> wrote:
> 
>> If the casts are always in one direction, can you make one protocol
>> refine another?
> 
> Yeah, I am shocked if they don't do that already.

They do; _NSFoo: _NSFooCore

But the problem is that we have _NSFooCores and want _NSFoos.

> 
>> 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.
> 
> Doesn't; we're not using these in a generic context; they're just
> existentials.
> 
>> 
>> 
>>> On Nov 4, 2016, at 4:29 PM, Alexis via swift-dev <swift-dev at swift.org> wrote:
>>> 
>>> The swift standard library has this nasty little pattern/problem in it:
>>> 
>>> The types in the core library want to know about several types
>>> defined in foundation: NSString, NSArray, NSDictionary, etc. But
>>> core is imported 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 Shadow Protocols 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.
>>> 
>>> However there’s sometimes two 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> _______________________________________________
>>> swift-dev mailing list
>>> swift-dev at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>> 
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
>> 
> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org <mailto:swift-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161107/97444c61/attachment.html>