I hate how Swift Strings don't let you access their characters with Ints. This package changes this:
someString[someString.index(someString.startIndex, offsetBy: 2) ... someString.index(someString.startIndex, offsetBy: 5)]to this:
import StringIntegerAccess
var someString = "Hello, World!"
someString[1...4] // "ello"
someString[7..<12] = "Mars" // "Hello, Mars!"If you prefer, you can also have the peace-of-mind that whatever integers you pass, it won't crash! Starting in version 2.0.0, you can now use [orNil:] subscripts, which will return the same values as the regular ones, but if you give them out-of-range indices, they return nil instead of crashing:
import SafeStringIntegerAccess
var someString = "Hello, World"
someString[orNil: 3..<5] == "lo"
someString[orNil: 3..<5] == someString[3..<5]
someString[orNil: 42..<99] == nil
someString[orNil: -10 ..< -5] == nil
someString[orNil: 7...] = "Mars!" // "Hello, Mars!"
someString[orNil: 999...] = "Boundaries" // "Hello, Mars!"Even better, this also implicitly imports StringIntegerAccess, so you don't have to double-up the imports!
This is exactly as performant as the long forms that it shortens. That said, the long form is often not very performant. As pointed out by Rob Napier on StackOverflow, since Swift String elements are Unicode characters, and since Unicode characters are an indeterminate number of codepoints long, and since the storage backing Strings is comprised of UTF-8 codepoints, there's no simple way to know how big a character is, so you can't just jump to anywhere in a string without reading everything before it first. In order to figure out "character n" you have to start at the beginning and decode everything, which is O(n).
So you write code like this, that feels very "safe":
for index in 0..<string.count { print(string[index]) }But secretly this is O(n^2) which is really surprising because it sure looks like O(n). You might say "well, my string is only 20 characters long, so who cares," but we use strings for lots of things, including multi-megabyte
NSTextStorage. (And this expands dramatically in Swift versus some other languages because Swift includes generic algorithms whose performance promises rely on the fact that subscripting is O(1).)
You can also learn more about why this was done in my StackOverflow question about why emoji like 👩👩👧👦 are treated so strangely in Swift Strings:
"\u{1112}\u{1161}\u{11AB}".contains("\u{1112}") // false
This is something you should be aware of anyway, if you're parsing big strings. It's just worth pointing out, here, that this sugar only sweetens the interface to a sour backend. If you're reading in and using lots of data, you should be using the Data type, which has Int subscripts already.