> On Oct 3, 2016, at 9:23 AM, Joe Groff <[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.
>
> -Joe
How would we square that with enum { case foo(StructX<Y>) } ? If we can
automatically bridge arbitrary enums and generic types then I’m all for it.
Russ_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
