[swift-dev] Emitting redundant protocol conformances to support type lookup

[Luke Howard]

Right, the point was to make it explicit so as to force a protocol conformance table entry to be emitted.

Sent from my iPhone

> On 8 Jan 2016, at 21:09, 肇鑫 <owenzx at gmail.com> wrote:
> 
> According to Swift docs on AnyObject,
>> The protocol to which all classes implicitly conform.
> ​So it is not ​an explicit conformance.​
> 
> ​http://swiftdoc.org/v2.1/protocol/AnyObject/
> 
> z​haoxin​
> 
>> On Fri, Jan 8, 2016 at 4:50 PM, Luke Howard via swift-dev <swift-dev at swift.org> wrote:
>> In the fix for [SR-381] (links at end) we implement an API for looking up classes by name by searching the protocol conformance table. The initial consumer of this is NSClassFromString() as used by NSKeyedUnarchiver in Foundation.
>> 
>> 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.
>> 
>> 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”.)
>> 
>> Before I proceed further down this path – is this an approach worth pursuing or would it be better not to abuse the conformance table for name lookups long term?
>> 
>> — Luke
>> 
>> https://bugs.swift.org/browse/SR-381
>> https://github.com/apple/swift/pull/834/files
>> 
>> --
>> www.lukehoward.com
>> soundcloud.com/lukehoward
>> 
>> 
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 
> 
> 
> -- 
> 
> Owen Zhao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160108/96f488e1/attachment-0001.html>