[swift-evolution] [swift-evolution-announce] [Review] SE-0083: Remove bridging conversion behavior from dynamic casts

[Rod Brown]

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 <swift-evolution at swift.org> wrote:
> 
> 
>> On May 23, 2016, at 5:26 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> 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 <swift-evolution at swift.org> 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
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160526/968e1a9e/attachment.html>