[swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations
dabrahams at apple.com
Tue Apr 5 15:39:45 CDT 2016
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:
> Reviews are an important part of the Swift evolution process. All reviews should
> be sent to the swift-evolution mailing list at
> 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
> Proposal link:
> 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
> • What is your evaluation of the proposal?
> • Is the problem being addressed significant enough to warrant a change to
> • 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:
they should definitely use “bridging” instead of “bridged,” since the
phrase describes *how* the conversion is going to be done.
Then, the “ObjectiveC” in the names looks like redundant type
information, suggesting this would be better:
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
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.
More information about the swift-evolution