<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">+1 from me; I’ve been dealing with a lot of conversion and yet it’s still pretty confusing largely because of the implicit conversions, it also goes against (pure) Swift’s elegant yet strictly typed checking system.</div><br class=""><div><blockquote type="cite" class=""><div class="">On 19 Apr 2016, at 04:21, Joe Pamer via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi everyone,<div class=""><br class=""></div><div class="">Prior to Swift 1.2, conversions between bridged Swift value types and their associated Objective-C types could be implicitly inferred in both directions. For example, you could pass an NSString object to a function expecting a String value, and vice versa.</div><div class=""><br class=""></div><div class="">In time we found this model to be less than perfect for a variety of reasons:</div><div class=""><ul class="MailOutline"><li class="">Allowing implicit conversions between types that lack a subtype relationship felt wrong in the context of our type system.</li><li class="">Importing Foundation would lead to subtle changes in how seemingly simple bodies of code were type checked.</li><li class="">The specific rules implemented by the compiler to support implicit bridging conversions were complex and ad-hoc.</li><li class="">Looking at the Swift code that had been written up until 1.2, these kinds of implicit conversions did not appear terribly common. (And where they <i class="">were</i> present, it wasn’t clear if users actually knew they were taking place.)</li></ul><div class=""><br class=""></div></div><div class="">In short, these conversions generally lead to a more confusing and unpredictable user model. So, for Swift 1.2, we sought to eliminate implicit bridging conversions entirely, and instead direct users to use explicit bridging casts in their place. (E.g., “<font face="Menlo" class="">nsStrObj as String</font>”.)</div><div class=""><br class=""></div><div class="">Unfortunately, when it came time to roll out these changes, we noticed that some native Objective-C APIs were now more difficult to work with in Swift 1.2. Specifically, because global Objective-C <font face="Menlo" class="">NSString*</font> constants are imported into Swift as having type <font face="Menlo" class="">String</font>, APIs that relied on string-constant lookups into dictionaries imported as <font face="Menlo" class="">[NSObject : AnyObject]</font> failed to compile. E.g.</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Menlo" class="">var s : NSAttributedString</font></div><div class=""><font face="Menlo" class="">let SomeNSFontAttributeName : String // As per the importer.</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class="">let attrs = s.attributesAtIndex(0, effectiveRange:nil) // In Swift 2, ‘attrs’ has type [NSObject : AnyObject]</font></div><div class=""><font face="Menlo" class="">let fontName = attrs[SomeNSFontAttributeName] // This will fail to compile without an implicit conversion from String to NSString.</font></div><div class=""><br class=""></div></blockquote>For this reason, we decided to make a compromise. We would require explicit bridging casts when converting from a bridged Objective-C type to its associated Swift value type (E.g., <font face="Menlo" class="">NSString</font> -> <font face="Menlo" class="">String</font>), but not the other way around. This would improve the status quo somewhat, and would also avoid breaking user code in a needless/painful fashion until we could get better API annotations in place.<div class=""><br class=""></div><div class="">With the introduction of Objective-C generics last year, along with all of the awesome improvements to API importing happening for Swift 3, I think it’s time that we take another look at completing this work. Taking a look back at last year’s “problematic” APIs, all of them now surface richer type information when imported into Swift 3. As a result, the remaining implicit bridging conversions now feel far less necessary, since Objective-C APIs are now more commonly exposed in terms of their appropriate bridged Swift value types. (For instance, in Swift 3, the above reference to <font face="Menlo" class="">attrs</font> will import as <font face="Menlo" class="">[String : AnyObject].</font>)</div><div class=""><br class=""></div><div class="">I propose that we fully eliminate implicit bridging conversions in Swift 3. This would mean that some users might have to introduce introduce a few more ‘as’ casts in their code, but we would remove another special case from Swift's type system and be able to further simplify the compiler. If anyone is curious and would like to take this model for a spin, I’ve pushed an experimental branch that implements this proposed change, <font face="Menlo" class="">inhibit-implicit-conversions</font>.</div><div class=""><br class=""></div><div class="">Thoughts?</div><div class=""><br class=""></div><div class="">Thanks!</div><div class="">- Joe</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>