[swift-dev] Emitting redundant protocol conformances to support type lookup
Luke Howard
lukeh at padl.com
Fri Jan 8 08:40:07 CST 2016
> The limitation of this approach is that only classes that explicitly conform to protocols can be resolved. We’ll work around this in Foundation by having subclasses that otherwise inherit their protocol conformance explicitly conform to a dummy protocol. However, this behaviour is confusing and would be nice to fix.
Sorry “we’ll work around this” sounds a bit presumptuous – what I meant was “it can be worked around”. :-)
> One approach I’ve been playing with is for classes always to have an explicit conformance to AnyObject (at least, if they don’t explicitly conform to anything else). (I have a bit of a hacky patch to implement this but it’s failing at link time as there’s no symbol for “_TMps9AnyObject”.)
Having IRGenModule::emitProtocolConformances() special case AnyObject to emit a zero reference solves the linkage issue. (RelativeIndirectablePointer will then return a bogus pointer, but maybe a Flag in the conformance record could be used to indicate null.)
This approach means the protocol conformance tables could get very large, but it has a fairly low impact to the compiler and runtime. An alternative might be to emit explicit entries only for classes that inherit from, say, NSObjectProtocol or NSCoding, and don’t conform to anything explicitly. Or classes could be marked as resolvable-by-name with some magic attribute (however this runs counter the goal of source code portability between Darwin and other platforms).
— Luke
More information about the swift-dev
mailing list