[swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations
adrian.kashivskyy at me.com
Wed Apr 6 04:02:19 CDT 2016
> • 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.
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,
> Wiadomość napisana przez Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> w dniu 06.04.2016, o godz. 03:08:
> (Sorry, sent without finishing a sentence.)
>>> 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
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution