[swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

[Dave Abrahams]

on Wed Apr 06 2016, Russ Bishop <swift-evolution at swift.org> wrote:

>     On Apr 5, 2016, at 1:39 PM, Dave Abrahams via swift-evolution
>     <swift-evolution at swift.org> wrote:
>
>     A few thoughts: 
>
>     1. It would have made it easier to evaluate if the proposal had not
>     talked about removing _ObjectiveCBridgeable and replacing it with a
>     new ObjectiveCBridgeable protocol, but what could more accurately be
>     described as de-underscoring the existing protocol and slightly
>     modernizing its API. The existing protocol was always intended to be
>     suitable for general use this way, and the design remains
>     substantially unchanged, so I support the proposal in principle.
>
> You can blame that on me; After changes from feedback I felt it different enough
> to call it a replacement.
>
>     2. These two APIs should look different IMO:
>
>     init?(bridgedFromObjectiveC: ObjectiveCType)
>     init(unconditionallyBridgedFromObjectiveC: ObjectiveCType?)
>
>     they should definitely use “bridging” instead of “bridged,” since the
>     phrase describes *how* the conversion is going to be done.
>
> Fair enough, IIRC some of the naming guidelines were still being decided when I
> wrote it up. 
> I’m not sure if the proposal needs to go back for revision and review again or
> if we can make minor changes during review but either way cleaning up the names
> (and removing the deprecated @warn_unused_result attribute) should be no
> problem.

However it's handled, I think more discussion is needed about these inits.

>     3. Is this proposal introducing a backdoor people can exploit to create
>     user-defined implicit conversions? If so, shouldn't that worry us?
>
> No. I explicitly call out in the doc that no implicit conversions are allowed
> except for the automatically generated thunks when importing Objective-C APIs
> into Swift. You must do an explicit cast in situations where the API can’t
> import automatically (eg: UnsafePointer<ObjCType>).

Great; sorry I missed that.

>     4. This proposal should probably support creating a type that only
>     bridges *from* Objective-C, to handle bridging mutable Objective-C
>     classes without an immutable base class to value types (anything else
>     breaks one of the languages' expectations of value or reference
>     semantics). This suggests a hierarchy of two protocols might be
>     warranted.
>
> I’m not quite following why it breaks the expectations of value or reference
> semantics. Are you talking about allowing a Swift type to bridge to either a
> mutable or immutable variant in ObjC? 

Consider NSPersonNameComponents, a mutable class in Cocoa.  If you want
to bridge that to a value type PersonNameComponents, then fine, you can
copy the data.  You had better not convert that value type back to
NSPersonNameComponents, though, or you're left with two bad choices:

1. You're converting by extracting an instance of NSPersonNameComponents
   from the implementation of PersonNameComponents, in which case ObjC
   code gets to modify the value of your PersonNameComponents instance.
   That's not value semantics.

2. You're converting by copying the data into a new
   NSPersonNameComponents, in which case ObjC code may have a reasonable
   expectation of being able to meaningfully modify the object and
   seeing that modification reflected somewhere, but it won't be.
   That's not reference semantics.

> In the proposal as written you’d presumably specify the bridging type
> as the mutable variant but importing the immutable variant does
> present a problem (it would violate the ambiguity rules if the types
> were defined in Swift) - is that what you were driving at?
>
> Russ
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave