+1 from me On Tue, Apr 19, 2016 at 8:42 AM, Haravikk via swift-evolution < [email protected]> wrote:
> +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. > > On 19 Apr 2016, at 04:21, Joe Pamer via swift-evolution < > [email protected]> wrote: > > Hi everyone, > > 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. > > In time we found this model to be less than perfect for a variety of > reasons: > > - Allowing implicit conversions between types that lack a subtype > relationship felt wrong in the context of our type system. > - Importing Foundation would lead to subtle changes in how seemingly > simple bodies of code were type checked. > - The specific rules implemented by the compiler to support implicit > bridging conversions were complex and ad-hoc. > - 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 *were* present, it wasn’t clear if users actually knew they were > taking place.) > > > 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., “nsStrObj as String”.) > > 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 NSString* constants > are imported into Swift as having type String, APIs that relied on > string-constant lookups into dictionaries imported as [NSObject : > AnyObject] failed to compile. E.g. > > var s : NSAttributedString > let SomeNSFontAttributeName : String // As per the importer. > > let attrs = s.attributesAtIndex(0, effectiveRange:nil) // In Swift 2, > ‘attrs’ has type [NSObject : AnyObject] > let fontName = attrs[SomeNSFontAttributeName] // This will fail to compile > without an implicit conversion from String to NSString. > > 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., NSString -> String), 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. > > 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 attrs will > import as [String : AnyObject].) > > 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, > inhibit-implicit-conversions. > > Thoughts? > > Thanks! > - Joe > _______________________________________________ > 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
