> On Oct 7, 2016, at 2:11 PM, Dave Abrahams via swift-evolution
> <[email protected]> wrote:
>
>
> on Mon Oct 03 2016, Joe Groff <[email protected]
> <mailto:[email protected]>> wrote:
>
>>> On Sep 30, 2016, at 10:48 PM, Russ Bishop <[email protected]> wrote:
>>>
>>>
>>>> On Sep 29, 2016, at 11:45 AM, Douglas Gregor via swift-evolution
>>>> <[email protected]>
>> wrote:
>>>>>
>>
>>>>
>>>>
>>>> Personally, I consider the first one to be a fairly-low-risk
>>>> extension to SE-0139 that’s borderline bug-fix. We already know
>>>> that those types have weak numeric representations in Objective-C
>>>> because they come from Objective-C, so losing some of the type info
>>>> by bridging to Objective-C is (IMO) falls out of having strong
>>>> types in Swift for weaker types in Objective-C.
>>>>
>>>> The second one makes me a little nervous, I think because it
>>>> weakens typing for types defined in Swift. These types don’t
>>>> naturally have Objective-C counterparts, so if we’re going to
>>>> weaken the types, it feels like we should only do so via some
>>>> explicit conformance (e.g., to a publicly-available form of
>>>> _ObjectiveCBridgeable).
>>>>
>>>> - Doug
>>>>
>>>
>>> I’m up for reviving the ObjectiveCBridgeable proposal :)
>>
>> I kind of hope id-as-Any leads us in a direction where
>> ObjectiveCBridgeable isn't necessary to expose for most user types. If
>> we at some point allow Swift value types to conform to ObjC protocols,
>> expose @objc methods, and opt in to being representable in ObjC as
>> classes, then most of the work of building an ObjC class to bridge to
>> could potentially be handled by the compiler.
>
> Well, ObjectiveCBridgeable is much too complicated for the semantics we
> need, but it's easy to imagine a simpler CustomObjectiveCBridgeable
> protocol that performs the same service. But it seems to me that coming
> up with a class representation and initializing it is the easy part, and
> that the “conforming to an ObjC protocol, exposing @objc methods, and
> opting in to being representable in ObjC as classes” part is essentially
> equivalent to conforming to CustomObjectiveCBridgeable.
>
> What am I missing?
Implementation-wise, it probably ends up looking similar. Once you're exposing
@objc methods, the only real practical way to do that is by realizing a
distinct ObjC class. Language-design-wise, it feels cleaner to me to push the
details of bridging user types under the hood as much as possible. Cocoa has
definite use for fully customizing the bridging interface to map core Swift
concepts to established ObjC interfaces, and perhaps there are a few third
parties who'd also like to dress up their established ObjC frameworks with a
modern, value-oriented Swift veneer, but I think we could automate the bridge
for the majority of users with higher-level features.
-Joe
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
