On Mar 21, 2015, at 18:55 , Charles Srstka <cocoa...@charlessoft.com> wrote:
> 
> The implicit conversions between String and NSString were removed in Swift 1.2

I’m sorry, I muddied the waters by using an incorrect description of “bridging” 
earlier.

Bridging in Obj-C is something like NSString vs CFString. The types and their 
APIs are formally distinct at compile time, even though the objects might be 
interchangeable at run time. If you use the “wrong” API for your declared type, 
you’ll get a compiler error, though the semantics of what you wrote might be 
sensible in terms of run-time behavior.

I think it’s the same thing in Swift: String and NSString are distinct types, 
and although their APIs almost exactly coincide, they’re not identical. (We 
found that UTF8String, for example, is in NSString but not String.) That 
implies the possibility of compile-time errors for things that might otherwise 
be meaningful in run-time terms. That’s what happened to Jens, I think.

However, I don’t think the level of run-time interoperability is exactly 
specified by API contract. It may be that there’s a shared toll-free bridged 
String/NSString object, or it may be that there are run-time conversions from 
“real” String objects to “real” NSString objects under some circumstances. It’s 
not obvious which of the two it is, though someone who knows more about Swift’s 
run-time than I do may be able to answer that definitively.

(Consider the parallel case of [Int] vs NSArray, which are AFAIK interoperable. 
However, they can’t be the same toll-free bridged objects, because we expect 
that [Int] doesn’t involve NSNumber objects in pure Swift, though they must in 
Obj-C. That suggests to me that there are potential conversions involved in the 
interoperability.)

Implicit *conversions* between String and NSString are something else again, 
because they presumably refer to assignments and initializations. But for 
Jens’s original expectation to have been satisfied, the Swift compiler would 
have to interpret s.UTF8String — where s is type String — by looking up 
UTF8String in a different class. That’s not a conversion but a hack, and the 
error message says that the hack doesn’t exist. (Also, I used Xcode 6.2 to try 
Jens’s playground code, and got the same error, so I don’t think the Xcode 
6.3/Swift 1.2 change matters on Jens’s issue.)

But I’m happy to be corrected on any of my mis-assumptions.



_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to