Swiftpack.co - Package - RougeWare/Swift-String-Integer-Access

Swift String Integer Access

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

someString[2...5]

Safety

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

let 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 

Even better, this also implicitly imports StringIntegerAccess, so you don't have to double-up the imports!

Performance

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 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.

Github

link
Stars: 0

Used By

Total: 0

Releases

2.0.0 - SafeStringIntegerAccess - 2020-05-22 19:42:44

More integer accessors, these without crashes! Drawing from Swift Safe Collection Access, you can now access strings with Ints, and if you pass an invalid value to these new orNil subscripts and functions, they will return nil instead of crashing!

import SafeStringIntegerAccess

let 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 

To take advantage of this new behavior, import SafeStringIntegerAccess. This will give the old behavior as well. If you just want the old behavior, import StringIntegerAccess instead.


Additionally, the NSRange subscript introduced in 1.2.0 now returns a Substring rather than an Optional<Substring>, crashing if the given range is invalid. For the non-crashing, optional-return behavior, pass your NSRange to the [orNil:] subscript.

In doing this update, the NSRange subscripts were updated to fix a bug with the way it processes strings with higher-plane Unicode characters and grapheme clusters.

1.2.0 - Added `NSRange` subscript - 2020-05-20 18:33:39

Allows you to just pass a NSRange to a String's subscript. Great for working with things like NSRegularExpression!

1.1.0 - Expanded support - 2020-03-03 03:39:46

Now supports all types conforming to StringProtocol, and all range subscripts

1.0.1 - MVP - 2020-02-29 00:50:24

Some basic integer-based string subscripts. If I continue to hit similar frustrating barriers, I'll add more to address those.