on Mon Apr 04 2016, Joe Groff <swift-evolution@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution