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

[Charlie Monroe]

Ditto. It's way too early to be doing this. This is something to be done when most major APIs are converted to Swift. This would make Swift hard to use for any interaction with JSON if you use NSJSONSerialization and pretty much with any NSDictionary...


> On May 25, 2016, at 6:49 AM, 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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160525/6f2f9c87/attachment.html>