on Tue Nov 08 2016, Michael Gottesman <mgottesman-AT-apple.com> wrote:
>> On Nov 7, 2016, at 11:23 AM, Alexis via swift-dev <swift-dev@swift.org> >> wrote: >> >> >>> On Nov 4, 2016, at 11:55 PM, Dave Abrahams via swift-dev >>> <swift-dev@swift.org > <mailto:swift-dev@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. > > I am confused. Then why can't you just do an unconditional checked down cast > to _NSFoo from > _NSFooCore? That can definitely be expressed at the SIL level? The check will fail. There is no actual relationship between the type and the protocol; we are just using the protocol to call some ObjC methods without being able to see the actual type's declaration. > > >> >>> >>>> 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@swift.org >>>>> <mailto:swift-dev@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@swift.org <mailto:swift-dev@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-dev >>>> >>>> _______________________________________________ >>>> swift-dev mailing list >>>> swift-dev@swift.org <mailto:swift-dev@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@swift.org <mailto:swift-dev@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-dev > <https://lists.swift.org/mailman/listinfo/swift-dev> >> _______________________________________________ >> swift-dev mailing list >> swift-dev@swift.org >> https://lists.swift.org/mailman/listinfo/swift-dev > -- -Dave _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
