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

[Brent Royal-Gordon]

(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