> 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. -Joe _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
