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

[Adrian Kashivskyy]

> • 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 <swift-evolution at swift.org> 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
> 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...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160406/33946caa/attachment.html>