<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=""><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 27, 2016, at 6:54, swizzlr 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=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Swift Foundation has an incomplete implementation of NSClassFromString/NSStringFromClass (link: <a href="https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSObjCRuntime.swift#L230-L282" class="">https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSObjCRuntime.swift#L230-L282</a>) due to a lack of a standardised method of encoding nested Swift classes, nor other Swift types.<br class=""><br class="">I would think that given<br class=""><br class="">module Contacts<br class=""><br class="">class Person {<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>struct Address {<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>class Postcode {}<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>}<br class="">}<br class=""><br class="">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?<br class=""><br class="">Tom</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=""></body></html>