[swift-evolution] [Pitch] Fully eliminate implicit bridging conversions in Swift 3

[T.J. Usiyan]

+1 from me

On Tue, Apr 19, 2016 at 8:42 AM, Haravikk via swift-evolution <
swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> 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
> 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/20160419/75b3fa7c/attachment.html>