Yes, I have to say Doug seems to be on the money with the concerns I hold with the current proposals about stripping out the "Objective-C Magic" in the bridge between Swift and Objective C.
There seems to be a strong push recently to rip out these APIs with clearly well meaning intent, but lack of consideration for the many APIs that this will make rather uncomfortable to use. I think this request tends to gloss over the fact that a vast majority of Swift code is still written for iOS and OS X and utilizes the Objective-C APIs extensively. As Doug points out, we are chipping away very fast at the bridging simplicity that made Swift brilliant to use on Apple Platforms, and I don't think the gains begin to approach the losses from these changes. While I agree strongly with the concept of wiping such bridges out where possible in concept, I am pragmatic that perhaps doing so is not in the best interests of Swift's usability in the short term at least. I think because we haven't experienced writing an Objective-C based app in Swift, we might be getting lost in the "concept" of stripping bridging, while missing the real world implications of such actions. - Rod > On 25 May 2016, at 2:49 PM, Douglas Gregor via swift-evolution > <[email protected]> wrote: > > >> On May 23, 2016, at 5:26 PM, Jordan Rose via swift-evolution >> <[email protected]> wrote: >> >> I am way late, but I share Brent’s concerns. I don’t think this addresses >> the very common case of “getting a String out of a heterogeneous dictionary”. >> >> let name = plist[“name”] as! String >> >> becomes one of these: >> >> let name = plist[“name”] as! NSString as String >> let name = String(plist[“name”] as! NSString) >> let name = String(forceBridging: plist[“name”]) // not in the proposal >> >> none of which I’m particularly happy with. > > I am also way, way late, here, but this ties into a philosophical concern I > have. The bridging that we have in place was designed to put Swift’s value > types front-and-center in the Swift experience, even when interoperating with > Objective-C APIs using reference-semantic types. It was a specific goal that > one should not have to juggle between Swift.Array and NSArray—NSArray is > bridged away in imported APIs, Swift arrays implicitly convert to AnyObject > when working an AnyObject-based API, dynamic bridging conversions would pass > through NSArray to get to Swift arrays, etc. So while one can certainly reach > for NS(Mutable)Array in Swift, one should not *have* to do so in Swift. > > This proposal and SE-0072 are chipping away at that bridging story, making > the explicit use of NSArray/NSString/etc. required for interoperability with > Objective-C APIs. While it does make the language more explicit and > predictable (and dynamic casting more efficient!), it makes the use of these > bridged reference-semantic more prevalent, which may lead to more overall > confusion about which set of types to use. There might even be a portability > argument: the current scheme lets you gloss over Any vs. AnyObject (which is > a current difference we see in ObjC Foundation vs. corelibs Foundation). > > - Doug > >> >> Jordan >> >> >>>> On May 19, 2016, at 02:31, Brent Royal-Gordon via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> * What is your evaluation of the proposal? >>> >>> The review is technically over, but I don't believe a decision has been >>> announced yet, so... >>> >>> I am generally in favor, but I have a serious concern about the readability >>> of certain conversions with this change. To wit, conversions like these: >>> >>> myArray as! [NSView] >>> myDictionary as! [String: NSView] >>> >>> Are about to become something more like these: >>> >>> [NSView](forcedLazyBridging: myArray) >>> [String: NSView](forcedLazyBridging: myDictionary) >>> >>> Or these: >>> >>> Array<NSView>(forcedLazyBridging: myArray) >>> Dictionary<String, NSView>(forcedLazyBridging: myDictionary) >>> >>> Either option is a significant regression in code readability compared to >>> the status quo. >>> >>> It's enough to make me wonder if we shouldn't have special-cased conversion >>> methods for NSArray, NSDictionary, and NSSet: >>> >>> myArray.of(NSView) // returns [NSView] >>> myDictionary.of(NSView, for: String) // returns [String: NSView] >>> mySet.of(NSView) // returns >>> Set<NSView> >>> >>> On the other hand, if you *don't* have to specify an element type, these >>> aren't so bad: >>> >>> Array(forcedLazyBridging: myArray) >>> Dictionary(forcedLazyBridging: myDictionary) >>> >>> And it gets even better if you use something a little saner than >>> `forcedLazyBridging` for the label. >>> >>>> * Is the problem being addressed significant enough to warrant a change >>>> to Swift? >>> >>> Yes. Conversions are a mess, and it'll be nice to clean them up. >>> >>>> * Does this proposal fit well with the feel and direction of Swift? >>> >>> Yes. >>> >>>> * If you have used other languages or libraries with a similar feature, >>>> how do you feel that this proposal compares to those? >>> >>> Most languages I've used have had much simpler cast systems with nothing >>> particularly close to Swift's bridging casts. >>> >>>> * How much effort did you put into your review? A glance, a quick >>>> reading, or an in-depth study? >>> >>> Quick reading. >>> >>> -- >>> Brent Royal-Gordon >>> Architechies >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
