[swift-evolution] [Pitch] Making some RawRepresentable things bridge to ObjC as their raw value

Dave Abrahams dabrahams at apple.com
Fri Oct 7 16:11:50 CDT 2016


on Mon Oct 03 2016, Joe Groff <swift-evolution at swift.org> wrote:

>> On Sep 30, 2016, at 10:48 PM, Russ Bishop <xenadu at gmail.com> wrote:
>> 
>> 
>>> On Sep 29, 2016, at 11:45 AM, Douglas Gregor via swift-evolution <swift-evolution at 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.

Well, ObjectiveCBridgeable is much too complicated for the semantics we
need, but it's easy to imagine a simpler CustomObjectiveCBridgeable
protocol that performs the same service.  But it seems to me that coming
up with a class representation and initializing it is the easy part, and
that the “conforming to an ObjC protocol, exposing @objc methods, and
opting in to being representable in ObjC as classes” part is essentially
equivalent to conforming to CustomObjectiveCBridgeable.

What am I missing?

-- 
-Dave



More information about the swift-evolution mailing list