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

[Russ Bishop]

> 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.



> 
> 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>).



> 
> 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? 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160406/0f5af826/attachment.html>