> On Nov 29, 2017, at 2:06 PM, Riley Testut <rileytes...@gmail.com> wrote:
>> On Nov 8, 2017, at 11:51 AM, Joe Groff <jgr...@apple.com> wrote:
>> In principle it makes sense, but there are implementation challenges we 
>> didn't have time to consider. It would be nice to make this happen when we 
>> have the time to make it work.
> Just out of curiosity, what were some of those implementation challenges? And 
> have any of these changed with the evolution of the standard library since 
> then?

One issue is that it would require a different boxing strategy for unbridged 
types. Right now, we have a single ObjC class in the Swift runtime for this 
purpose (you may have seen objects of class _SwiftValue coming from Swift value 
types in ObjC). If Swift value types can conform to ObjC protocols, then we may 
need to instantiate a boxing ObjC class per conforming value type on which to 
hang those conformances. We wouldn't want to emit an ObjC class for every type 
declaration in Swift, because that'd have significant metadata size and startup 
time costs, but since modules can extend types that don't belong to them to 
conform to additional protocols, we can't know with confidence whether a type 
needs an objc class for this purpose, and thanks to dlopen, that may even 
change at runtime. Also, since ObjC generics are based on type erasure, but 
bridging in some situations relies on reified runtime type information, we need 
to think through whether it's possible in all situations you'd call an ObjC 
generic from Swift to keep the type information around on the Swift side to 
bridge outputs back.

swift-evolution mailing list

Reply via email to