This is somewhat intentional. While simple names can be encoded hierarchically like this, generics make everything more tricky. Consider a demangled name "Contacts.Person.Address<AddressKit.UnitedStates>.PostCode"—in this case not only is splitting on "." is no longer a reasonable thing to do, but there's not currently a way to get the type for 'Address' with a particular generic argument.
The Swift compiler and Foundation teams were a bit at odds here, trying to decide whether it would be appropriate to use Swift's current mangling scheme for encoded class names, or whether it would be better to pick something else. (This is what the Objective-C runtime currently does on Apple platforms, but that too could be changed, though we'd have to be careful about backward-compatibility.) IIRC at the time we decided it was best to implement the minimal thing that handles the common case—top-level non-generic types—and worry about the more complicated things later. Jordan > On Oct 27, 2016, at 6:54, swizzlr via swift-dev <swift-...@swift.org> wrote: > > Swift Foundation has an incomplete implementation of > NSClassFromString/NSStringFromClass (link: > https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSObjCRuntime.swift#L230-L282 > > <https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSObjCRuntime.swift#L230-L282>) > due to a lack of a standardised method of encoding nested Swift classes, nor > other Swift types. > > I would think that given > > module Contacts > > class Person { > struct Address { > class Postcode {} > } > } > > Postcode would be encoded as Contacts.Person.Address.Postcode. Since it is > not possible to have two different types with the same identifier in the same > namespace (i.e. an enum/a class/a struct with the same name at the same > declaration level) the encoding would similarly be simple. May I proceed > under that assumption or are there ABI stability issues I have yet to > consider? > > Tom > _______________________________________________ > swift-dev mailing list > swift-...@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
