> • What is your evaluation of the proposal? +1, been a supporter of this idea from the very beginning.
> • Is the problem being addressed significant enough to warrant a change to > Swift? It is when doing hybrid (Objective-C plus Swift) development. > • Does this proposal fit well with the feel and direction of Swift? Not with the direction of Swift itself but it certainly helps with the transition from Objective-C. > • How much effort did you put into your review? A glance, a quick reading, or > an in-depth study? Been following the topic since the beginning. ––– One thing, I noticed the proposal includes @warn_unused_result attribute in one of code examples. As this will be removed per SE-0047, I suggest removing the attribute from the proposal code examples. Pozdrawiam – Regards, Adrian Kashivskyy > Wiadomość napisana przez Brent Royal-Gordon via swift-evolution > <[email protected]> w dniu 06.04.2016, o godz. 03:08: > > (Sorry, sent without finishing a sentence.) > >>> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md >> >>> 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. >> >> I really don't like these two differing only by the optionality of their >> argument and return type, especially if they're going to have *no* argument >> label, which will make them look very attractive. And the unconditional one >> has many strange semantics—the extra layer of optionality on the argument, >> the fact that it may *lazily* crash if you access a sub-object which isn't >> permitted, etc. So I would at least label that one: >> >> init?(_ source: ObjectiveCType) >> init(forced source: ObjectiveCType?) >> >> I'm also a little worried about having an `init?(_:)` when a particular >> conversion might reasonably always succeed. The lack of a label will imply >> to users that this is something they can use directly; > > if the conversion always succeeds, though, it will unnecessarily be returning > an optional value. (And from what I can tell, you can't satisfy an optional > return value in a protocol with a member having a non-optional return value. > Not sure why that is.) > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
