Swift - which types to use? NSString or String

后端 未结 9 988
死守一世寂寞
死守一世寂寞 2020-12-23 00:06

With the introduction of Swift I\'ve been trying to get my head round the new language

I\'m an iOS developer and would use types such as NSString, NSInteger, N

相关标签:
9条回答
  • 2020-12-23 00:45

    You should use the Swift native types whenever possible. The language is optimized to use them, and most of the functionality is bridged between the native types and the Foundation types.

    While String and NSString are mostly interchangeable, i.e, you can pass String variables into methods that take NSString parameters and vice versa, some methods seem to not be automatically bridged as of this moment. See this answer for a discussion on how to get the a String's length and this answer for a discussion on using containsString() to check for substrings. (Disclaimer: I'm the author for both of these answers)

    I haven't fully explored other data types, but I assume some version of what was stated above will also hold true for Array/NSArray, Dictionary/NSDictionary, and the various number types in Swift and NSNumber

    Whenever you need to use one of the Foundation types, you can either use them to type variables/constants explicitly, as in var str: NSString = "An NSString" or use bridgeToObjectiveC() on an existing variable/constant of a Swift type, as in str.bridgeToObjectiveC().length for example. You can also cast a String to an NSString by using str as NSString.

    However, the necessity for these techniques to explicitly use the Foundation types, or at least some of them, may be obsolete in the future, since from what is stated in the language reference, the String/NSString bridge, for example, should be completely seamless.

    For a thorough discussion on the subject, refer to Using Swift with Cocoa and Objective-C: Working with Cocoa Data Types

    0 讨论(0)
  • 2020-12-23 00:45

    Since the objective C types are still dynamically dispatched they're probably going to be slower. I'd say you're best served using the Swift native types unless you need to interact with objective-c APIs

    0 讨论(0)
  • 2020-12-23 00:46

    Use the Swift native types whenever you can. In the case of String, however, you have "seamless" access to all the NSString methods like this:

    var greeting = "Hello!"
    var len = (greeting as NSString).length
    
    0 讨论(0)
  • 2020-12-23 00:47

    Swift 4 update

    String gets revisions in swift 4. Now you can directly call count on it and it consider grapheme clusters as 1 piece, like an emoji. NSString is not updated and is counting it in another way.

    var nsstring: NSString = "                                                                    
    0 讨论(0)
  • 2020-12-23 00:53

    Your best bet is to use Swift native types and classes, as some others have noted NSString has toll free translation to String, however, they're not the same a 100%, take for example the following

    var nsstring: NSString = "\U0001F496"
    var string: String = "\U0001F496"
    
    nsstring.length
    count(string)
    

    you need to use the method count() to count the characters in string, also note that nsstring.length returns 2, because it counts its length based on UTF16.

    Similar, YES The same, NO

    0 讨论(0)
  • 2020-12-23 00:54

    Swift Strings are quite elegant and easy to use, unless you need to parse them. The whole concept of indexing into Swift strings is just plain crazy. Whenever I need to parse through a typical unicode string, I convert it to NSString. Swift makes this a bit tricky though in that the common "character" integer expressions like ' ' or 'A' or '0' don't work in Swift. You have to use 32, 65, 48. Unfortunately, I'm not kidding! Because of this, I've put most of my string parsing code into an NSString extension written in Objective-C.

    Yes I do know WHY Swift's designers made String indexing so crazy: They wanted to be able to express many-byte characters like emoji as single "Characters". My choice would have been to let this rare use case be expressed as multiple UTF16 characters, but what the heck.

    0 讨论(0)
提交回复
热议问题