[swift-dev] Emitting redundant protocol conformances to support type lookup
rjmccall at apple.com
Fri Jan 8 11:09:04 CST 2016
> On Jan 8, 2016, at 6:40 AM, Luke Howard via swift-dev <swift-dev at swift.org> wrote:
>> 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).
I’m pretty opposed to wasting a bunch of space in the binary on formal protocol conformances that can be easy rederived by just checking whether the conforming type is a class type. AnyObject is a special case in the compiler; it makes sense for it to be a special case in the runtime conformance checking routines.
More information about the swift-dev