[swift-dev] Reconsidering the global uniqueness of type metadata and protocol conformance instances

Jordan Rose jordan_rose at apple.com
Mon Jul 31 11:50:11 CDT 2017

> On Jul 29, 2017, at 13:20, Chris Lattner <clattner at nondot.org> wrote:
>> On Jul 28, 2017, at 3:59 PM, Jordan Rose via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>>> So generic code to instantiate type metadata would have to construct these mangled strings eagerly?
>>> We already do exactly that for the ObjC runtime name of generic class instantiations, for what it's worth, but it could conceivably be lazy as well, at the cost of making the comparison yet more expensive. There aren't that many runtime operations that need to do type comparison, though—the ones I can think of are casting and the equality/hashing operations on Any.Type—so how important is efficient type comparison?
>> I'm still strongly against any feature that relies on type names being present at runtime. I think we should be able to omit those for both code size and secrecy reasons when the type isn't an @objc class or protocol.
> Out of curiosity, is there something that strongly motivates this?  Aren’t code obfuscation tools good enough for the few people who care?
> Actually achieving “secrecy” would require revising the mangling scheme and making lots of other changes to the runtime metadata.  This would be very complicated and expensive, and almost no one cares AFAIK.

I've got a pile of secrecy-related Radars that says it's at least worth thinking about. I don't think it matters for public symbols but for non-public ones C people are used to being able to use names freely, even if Objective-C people know they can show up in the runtime metadata.

(We've also gotten complains that there aren't good code obfuscation tools for Swift, since we don't have a preprocessor. That's a separable issue, though.)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170731/d5e8603d/attachment.html>

More information about the swift-dev mailing list