On Mar 21, 2015, at 8:59 PM, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote: > On Mar 21, 2015, at 20:43 , Charles Srstka <cocoa...@charlessoft.com> 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
