> On Jul 29, 2017, at 13:20, Chris Lattner <clatt...@nondot.org> wrote: > > >> On Jul 28, 2017, at 3:59 PM, Jordan Rose via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@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.) Jordan
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
