+1! To me, it feels like the ambivalent dynamic casting is a temporary complexity, and that at some point in the future the need to expose legacy reference types like NSString outside swift-supplied or user-created bridging code will disappear completely.
This also will get rid of some of the rough edges in the various corelibs where value types cannot be supported because some platforms have a backing library written in Objective-C. Swiftier indeed! Is this something you are pushing for in Swift 3? It seems appropriate but ambitious. Just to cement my own understanding of the ambivalent dynamic casting - would the behavior be similar if the clang importer took id references and embedded them into a Bridgeable wrapper to defer bridging, and this Bridgeable wrapper (as well as Array, Dictionary and Set) was understood by the language to participate in as‽ behavior? -DW > On Jul 1, 2016, at 5:37 PM, Joe Groff via swift-evolution > <[email protected]> wrote: > > Hi everyone. After implementing SE-0072, disabling the implicit bridging > conversions from Swift value types to classes > (https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md), > we immediately observed a severe negative impact on Cocoa interop as our > users at Apple adapted to the change, forcing us to roll it back. `id`-based > interfaces are still all over the place in the Cocoa SDKs, but it's our goal > that Swift programmers should be able to use the value type versions of > things without being constantly confronted with marshalling in and out of > their `NS` versions, and this change failed that test for Cocoa users. > Furthermore, the Foundation corelibs team is interested in continuing to > adopt more value types and improving the experience of using Foundation from > Swift without being hamstrung by the limitations of ObjC interop. We can > address the problem of value-type-to-id interfacing in a different > way—instead of making it a special case in the type system, we can handle it > in the Objective-C bridge instead, by bridging Objective-C's `id` type to > `Any` instead of `AnyObject`. This is a big change, but I think it leads to > an overall Swiftier and more flexible model. I'm working on a proposal to > this effect and would like to start getting feedback on it. Thanks for taking > a look! > > https://github.com/jckarter/swift-evolution/blob/1316004246e45296f81582477d70c22f95ec106c/proposals/XXXX-id-as-any.md > > -Joe > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
