Thanks all, I’ll take this info to try to come up with a draft proposal for encoding after having done deeper research into the ins and outs of the current options and decisions made.
Appreciate the kind and useful responses! Tom > 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-dev at > > 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-dev at swift.org > > https://lists.swift.org/mailman/listinfo/swift-dev > > > _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
