Re: Why is NSString.UTF8String unavailable in Swift?

[Greg Parker]

On Mar 21, 2015, at 8:59 PM, Quincey Morris 
 wrote:
> On Mar 21, 2015, at 20:43 , Charles Srstka  wrote:
>> I’m pretty sure that “real” Swift strings are different from NSStrings at 
>> runtime. It’s not like NSString/CFString; it has to do an actual conversion, 
>> and is not toll-free bridged. If you convert between String and NSString a 
>> lot, it’ll have performance implications (which is why bridging to NSString 
>> just to get -UTF8String isn’t really a good idea).
> 
> What’s interesting about that is (assuming my playground test is correct) the 
> native Swift String type only “acquires” cStringUsingEncoding when Cocoa is 
> imported.
> 
> That means either:
> 
> a. The native class actually has that method, but doesn’t expose it to the 
> world without “import Cocoa”, OR
> 
> b. The native class must implement some kind of selector forwarding that 
> translates that method into a message to a real NSString conversion of the 
> String instance, or some such roundabout thing.
> 
> Option (a) seems strange, but option (b) seems even stranger.

c. None of the above.

When you `import Cocoa` in Swift code you get some Swift additions as well as 
Cocoa's Objective-C declarations. 

Most of NSString's methods are re-implemented in a Swift extension on class 
String. You get this extension when you `import Cocoa`.

UTF8String was deliberately omitted from the extension on class String because 
String already has a `utf8` property. If you think String.UTF8String should be 
supported then you should file a bug report.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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

Re: Why is NSString.UTF8String unavailable in Swift?

[Fritz Anderson]

> On 21 Mar 2015, at 11:10 PM, Jens Alfke  wrote:
> 
> 
>> On Mar 21, 2015, at 8:43 PM, Charles Srstka  wrote:
>> 
>> If you convert between String and NSString a lot, it’ll have performance 
>> implications (which is why bridging to NSString just to get -UTF8String 
>> isn’t really a good idea).
> 
> Then what would be the best way, given a String, to pass it to a C API that 
> wants a char*?
> 
> —Jens

À propos of Swift 1.1:



var str = "Hello, playground"
str.UTF8String  // String does not implement



import Foundation   // Let’s be minimal
var str = "Hello, playground"
str.UTF8String  //String does not implement



import Foundation
var str = "Hello, playground"
(str as NSString).UTF8String
// Swift >= 1.1 does not implicitly convert String -> NSString.
// You have to force the conversion.



— F


___

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

Re: Why is NSString.UTF8String unavailable in Swift?

[Kyle Sluder]

On Sat, Mar 21, 2015, at 10:10 PM, Jens Alfke wrote:
> 
> > On Mar 21, 2015, at 8:43 PM, Charles Srstka  
> > wrote:
> > 
> > If you convert between String and NSString a lot, it’ll have performance 
> > implications (which is why bridging to NSString just to get -UTF8String 
> > isn’t really a good idea).
> 
> Then what would be the best way, given a String, to pass it to a C API
> that wants a char*?

String has a .utf8 property that returns a UTF8View. UTF8View is a
Collection of UInt8, and therefore a SequenceType.

Array has an initializer that takes a SequenceType.

--Kyle Sluder

___

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

Re: Why is NSString.UTF8String unavailable in Swift?

[Jens Alfke]

> On Mar 21, 2015, at 8:43 PM, Charles Srstka  wrote:
> 
> If you convert between String and NSString a lot, it’ll have performance 
> implications (which is why bridging to NSString just to get -UTF8String isn’t 
> really a good idea).

Then what would be the best way, given a String, to pass it to a C API that 
wants a char*?

—Jens
___

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

Re: Why is NSString.UTF8String unavailable in Swift?

[Quincey Morris]

On Mar 21, 2015, at 20:43 , Charles Srstka  wrote:
> 
> I’m pretty sure that “real” Swift strings are different from NSStrings at 
> runtime. It’s not like NSString/CFString; it has to do an actual conversion, 
> and is not toll-free bridged. If you convert between String and NSString a 
> lot, it’ll have performance implications (which is why bridging to NSString 
> just to get -UTF8String isn’t really a good idea).

What’s interesting about that is (assuming my playground test is correct) the 
native Swift String type only “acquires” cStringUsingEncoding when Cocoa is 
imported.

That means either:

a. The native class actually has that method, but doesn’t expose it to the 
world without “import Cocoa”, OR

b. The native class must implement some kind of selector forwarding that 
translates that method into a message to a real NSString conversion of the 
String instance, or some such roundabout thing.

Option (a) seems strange, but option (b) seems even stranger.

___

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

Re: Why is NSString.UTF8String unavailable in Swift?

[Charles Srstka]

> On Mar 21, 2015, at 9:28 PM, Quincey Morris 
>  wrote:
> 
> On Mar 21, 2015, at 18:55 , Charles Srstka  > 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.

I’m pretty sure that “real” Swift strings are different from NSStrings at 
runtime. It’s not like NSString/CFString; it has to do an actual conversion, 
and is not toll-free bridged. If you convert between String and NSString a lot, 
it’ll have performance implications (which is why bridging to NSString just to 
get -UTF8String isn’t really a good idea).

Charles

___

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

Re: Why is NSString.UTF8String unavailable in Swift?

[Quincey Morris]

On Mar 21, 2015, at 18:55 , Charles Srstka  wrote:
> 
> The thing that’s odd is that the native Swift String’s implementation of 
> cStringUsingEncoding uses the Foundation NSStringEncoding constants instead 
> of something that wouldn’t require importing Foundation.

> On Mar 21, 2015, at 18:46 , Jens Alfke  wrote:
> 
> The implication there is that String inherits all methods of NSString, not 
> that most of the NSString methods have been manually copied into String.


One more thing…

Jens is correct, actually. If you remove the “import Cocoa” from the 
playground, you’ll see that the basic String class doesn’t even have 
cStringUsingEncoding. (!)

So, I conclude, importing NSString.h:

— adds NSString methods to class String as an extension, AND

— adds an entirely new NSString class with the NSString methods, BUT

— for some reason, omits UTF8String in the first case, but adds it in the 
second case.




___

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

Re: Why is NSString.UTF8String unavailable in Swift?

[Quincey Morris]

On Mar 21, 2015, at 18:55 , Charles Srstka  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

Re: Why is NSString.UTF8String unavailable in Swift?

[Charles Srstka]

> On Mar 21, 2015, at 6:41 PM, Jens Alfke  wrote:
> 
>> On Mar 21, 2015, at 2:13 PM, Quincey Morris 
>> > > wrote:
>> 
>> Well, “String” is not “NSString”.
> 
> Sure, but it’s bridged with NSString. The “Using Swift With Cocoa” book says: 
> “Swift automatically bridges between the String type and the NSString class. 
> This means that anywhere you use an NSString object, you can use a Swift 
> String type instead  … you should almost never need to use the NSString class 
> directly in your own code.”

The implicit conversions between String and NSString were removed in Swift 1.2, 
in order to make the type system “simpler and more predictable". The 
documentation you’re quoting is simply out of date.

> On Mar 21, 2015, at 6:58 PM, Quincey Morris 
>  wrote:
> 
> The difference is mundane: String happens to have a “cStringUsingEncoding” 
> method, but not a “UTF8String” method. NSString happens to have both. I don’t 
> know why — though I can’t imagine it’s merely been overlooked in a class as 
> common as String — but that difference is the reason for the error message.

The thing that’s odd is that the native Swift String’s implementation of 
cStringUsingEncoding uses the Foundation NSStringEncoding constants instead of 
something that wouldn’t require importing Foundation.

Charles

___

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

Re: Why is NSString.UTF8String unavailable in Swift?

[Jens Alfke]

> On Mar 21, 2015, at 4:58 PM, Quincey Morris 
>  wrote:
> 
> When you used “cStringUsingEncoding”, you weren’t bridging to the NSString 
> method, you were using String’s native method of the same name.

Aha. That was not at _all_ clear from the docs. The implication there is that 
String inherits all methods of NSString, not that most of the NSString methods 
have been manually copied into String.

> It’s possible that String’s cStringUsingEncoding is internally calling 
> through to NSString’s, but I wouldn’t bet on it.

I'd bet money on it, actually. There's no reason for them to rewrite those 
methods. And the annotation "[Foundation]" on many of the String method docs 
surely means that they're bridged to the NSString implementations.

Anyway, thanks for clearing that up.

--Jens
___

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

Re: Why is NSString.UTF8String unavailable in Swift?

[Jens Alfke]

—Jens 

> On Mar 21, 2015, at 5:09 PM, Kevin Meaney  wrote:
> 
> But the bridging only happens if you import Foundation, otherwise there is no 
> NSString to bridge with.

I did import Foundation. I showed that clearly in the code snippets in my first 
message.

--Jens
___

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

Re: Why is NSString.UTF8String unavailable in Swift?

[Kevin Meaney]

Sent from my iPad

> On 21 Mar 2015, at 23:41, Jens Alfke  wrote:
> 
> 
>> On Mar 21, 2015, at 2:13 PM, Quincey Morris 
>>  wrote:
>> 
>> Well, “String” is not “NSString”.
> 
> Sure, but it’s bridged with NSString. The “Using Swift With Cocoa” book says: 
> “Swift automatically bridges between the String type and the NSString class. 
> This means that anywhere you use an NSString object, you can use a Swift 
> String type instead  … you should almost never need to use the NSString class 
> directly in your own code.”

But the bridging only happens if you import Foundation, otherwise there is no 
NSString to bridge with.

> 
>>var str = "Hello, playground” as NSString
>>str.cStringUsingEncoding(NSUTF8StringEncoding) // OK
>>str.UTF8String  // OK
> 
> -cStringUsingEncoding: and several other NSString methods I’ve tried work 
> without the “as NSString” trick; what’s special about “UTF8String”?
> 
> —Jens
> ___
> 
> 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/ktam%40yvs.eu.com
> 
> This email sent to k...@yvs.eu.com

___

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

Re: Why is NSString.UTF8String unavailable in Swift?

[Quincey Morris]

On Mar 21, 2015, at 16:41 , Jens Alfke  wrote:
> 
> Sure, but it’s bridged with NSString. The “Using Swift With Cocoa” book says: 
> “Swift automatically bridges between the String type and the NSString class. 
> This means that anywhere you use an NSString object, you can use a Swift 
> String type instead  … you should almost never need to use the NSString class 
> directly in your own code.”

Yes, but there’s there’s no opportunity for bridging in your code. Bridging 
means that when String is used where NSString is expected, or vice versa, 
there’s an implicit type conversion. The variable was of type “String”, used in 
a context where String was expected, and type String has no “UTF8String” 
property. No appeal to NSString was made or implied by your code — there’s no 
reason why a random method/property name should be looked up in any other class.

> -cStringUsingEncoding: and several other NSString methods I’ve tried work 
> without the “as NSString” trick; what’s special about “UTF8String”?


The difference is mundane: String happens to have a “cStringUsingEncoding” 
method, but not a “UTF8String” method. NSString happens to have both. I don’t 
know why — though I can’t imagine it’s merely been overlooked in a class as 
common as String — but that difference is the reason for the error message.

When you used “cStringUsingEncoding”, you weren’t bridging to the NSString 
method, you were using String’s native method of the same name. It’s possible 
that String’s cStringUsingEncoding is internally calling through to NSString’s, 
but I wouldn’t bet on it.




___

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

Re: Why is NSString.UTF8String unavailable in Swift?

[Jens Alfke]

> On Mar 21, 2015, at 2:13 PM, Quincey Morris 
>  wrote:
> 
> Well, “String” is not “NSString”.

Sure, but it’s bridged with NSString. The “Using Swift With Cocoa” book says: 
“Swift automatically bridges between the String type and the NSString class. 
This means that anywhere you use an NSString object, you can use a Swift String 
type instead  … you should almost never need to use the NSString class directly 
in your own code.”

>   var str = "Hello, playground” as NSString
>   str.cStringUsingEncoding(NSUTF8StringEncoding) // OK
>   str.UTF8String  // OK

-cStringUsingEncoding: and several other NSString methods I’ve tried work 
without the “as NSString” trick; what’s special about “UTF8String”?

—Jens
___

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

Re: Why is NSString.UTF8String unavailable in Swift?

[Quincey Morris]

On Mar 21, 2015, at 14:02 , Jens Alfke  wrote:
> 
>   let s = “……”
>   some_function(s.UTF8String)

Well, “String” is not “NSString”.

So:
import Cocoa
var str = "Hello, playground” as NSString
str.cStringUsingEncoding(NSUTF8StringEncoding) // OK
str.UTF8String  // OK


___

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