Re: Why is NSString.UTF8String unavailable in Swift?
Re: Why is NSString.UTF8String unavailable in Swift?
- Subject: Re: Why is NSString.UTF8String unavailable in Swift?
- From: Quincey Morris <email@hidden>
- Date: Sun, 22 Mar 2015 02:28:39 +0000
On Mar 21, 2015, at 18:55 , Charles Srstka <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden