> On Sep 30, 2016, at 10:48 PM, Russ Bishop <xen...@gmail.com> wrote: > > >> On Sep 29, 2016, at 11:45 AM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org> wrote: >>> >> >> >> Personally, I consider the first one to be a fairly-low-risk extension to >> SE-0139 that’s borderline bug-fix. We already know that those types have >> weak numeric representations in Objective-C because they come from >> Objective-C, so losing some of the type info by bridging to Objective-C is >> (IMO) falls out of having strong types in Swift for weaker types in >> Objective-C. >> >> The second one makes me a little nervous, I think because it weakens typing >> for types defined in Swift. These types don’t naturally have Objective-C >> counterparts, so if we’re going to weaken the types, it feels like we should >> only do so via some explicit conformance (e.g., to a publicly-available form >> of _ObjectiveCBridgeable). >> >> - Doug >> > > I’m up for reviving the ObjectiveCBridgeable proposal :)
I kind of hope id-as-Any leads us in a direction where ObjectiveCBridgeable isn't necessary to expose for most user types. If we at some point allow Swift value types to conform to ObjC protocols, expose @objc methods, and opt in to being representable in ObjC as classes, then most of the work of building an ObjC class to bridge to could potentially be handled by the compiler. -Joe _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
