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

[Dave Abrahams]

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

> Hello Swift community,
>
> The review of “Allow Swift types to provide custom Objective-C representations”
> begins now and runs through April 11, 2016. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md
>
> Reviews are an important part of the Swift evolution process. All reviews should
> be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the review
> manager. When replying, please try to keep the proposal link at the top of the
> message:
>
> Proposal link:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md
>
> Reply text
>
> Other replies
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review through
> constructive criticism and, eventually, determine the direction of Swift. When
> writing your review, here are some questions you might want to answer in your
> review:
>
> • What is your evaluation of the proposal?
> • Is the problem being addressed significant enough to warrant a change to
> Swift?
> • Does this proposal fit well with the feel and direction of Swift?
> • If you have used other languages or libraries with a similar feature, how do
> you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick reading, or an
> in-depth study?

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.

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.

      init?(bridgingFromObjectiveC: ObjectiveCType)
      init(unconditionallyBridgingFromObjectiveC: ObjectiveCType?)

    Then, the “ObjectiveC” in the names looks like redundant type
    information, suggesting this would be better:

      init?(bridgingFrom: ObjectiveCType)
      init(unconditionallyBridgingFrom: ObjectiveCType?)

    But then, these *are* intended to be full-width type conversions,
    are they not?  Why not these:

      init?(_ source: ObjectiveCType)
      init(_ source: ObjectiveCType?)

    ?  If any of these transformations are wrong, it would good to have
    a rationale as to why.


3. Is this proposal introducing a backdoor people can exploit to create
   user-defined implicit conversions?  If so, shouldn't that worry us?

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.

5. For the version of the protocol that does bridge back to Objective-C,
   maybe something should be done to make it more clear that the
   ObjectiveCType must be immutable.  Perhaps that means doing this
   without a protocol hierarchy and using a different associated type
   name in the two protocols; I don't know.

-- 
Dave