[Pitch] Fully eliminate implicit bridging conversions in Swift 3


(Joe Pamer) #1

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


(Jacob Bandes-Storch) #2

Is it true that some CF APIs, such as these, are still imported as CFString
instead of String?

https://github.com/apple/swift-3-api-guidelines-review/blob/swift-3/Platforms/OSX/CoreText/CTFontTraits.swift#L2-L9

···

On Mon, Apr 18, 2016 at 8:21 PM, Joe Pamer via swift-evolution < swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Greg Parker) #3

What happens with string literals? Are they implicitly converted to NSString as necessary? Which of the following will be legal?

    import Foundation
    func s(_ str: String) { }
    func ns(_ str: NSString) { }

    let str: String = "foo"
    let nsstr: NSString = "foo"

    NSLog("foo")
    NSLog(str)
    NSLog(nsstr)

    s("foo")
    s(str)
    s(nsstr)

    ns("foo")
    ns(str)
    ns(nsstr)

···

On Apr 18, 2016, at 8:21 PM, Joe Pamer via swift-evolution <swift-evolution@swift.org> wrote:

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.

--
Greg Parker gparker@apple.com Runtime Wrangler


(Haravikk) #4

+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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Vladimir) #5

I fully support this proposal. IMO we should be moving forward and improve Swift, separate it from ObjC and explicitly bridge when needed.

···

On 19.04.2016 6:21, Joe Pamer via swift-evolution 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(TJ Usiyan) #6

+1 from me

···

On Tue, Apr 19, 2016 at 8:42 AM, Haravikk via swift-evolution < swift-evolution@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Joe Pamer) #7

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.

What happens with string literals? Are they implicitly converted to NSString as necessary?

Sort of - yes. The types of literal expressions are always inferred from context, so for string literals they will be inferred as NSString or String as necessary.

Which of the following will be legal?

    import Foundation
    func s(_ str: String) { }
    func ns(_ str: NSString) { }

    let str: String = "foo"
    let nsstr: NSString = "foo"

    NSLog("foo”)

legal

    NSLog(str)

legal - the NSLog initializer is imported as having type func NSLog(_ format: String, _ args: CVarArg...)

    NSLog(nstr)

illegal, per the imported initializer declaration above

    s("foo”)

legal

    s(str)

legal

    s(nsstr)

illegal

    ns("foo”)

legal

    ns(str)

illegal

    ns(nsstr)

legal

Thanks,
- Joe

···

On Apr 19, 2016, at 7:28 AM, Greg Parker <gparker@apple.com> wrote:

On Apr 18, 2016, at 8:21 PM, Joe Pamer via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

--
Greg Parker gparker@apple.com <mailto:gparker@apple.com> Runtime Wrangler