A while back, I posted about counting strings in Swift.  I discovered that countElements() offered the most consistently correct results regardless of string content. Time has passed. With Swift 1.2,  countElements() has been replaced with count(), which of course has made updating code and libraries a great deal of fun because there’s nothing more exciting than a language past its 1.0 debut that continues to change syntax details.

Last night, I ran into an interesting string counting situation with countElements()/count()/countChocula()  even as I doggedly insisted on its superior correctness in string testing.

Ken Ferry pointed out that the count call requires O(N) time. In comparison, utf16count is O(1). As my previous experiments showed, when you’re using complex strings with emoji, the answer with utf16count will be wrong but as Ken correctly noted, you’ll get the wrong answer really fast. For a 33554432-character string I threw together, that answer took 8.42 seconds with count and 3.6e-05 with utf16count. Pretty big performance difference.

So why do O(1) results matter? As Ken pointed out, “Wrong depends on why you’re looking at it.” There’s no instance in which the utf16count will be wrong for zero length checks, such as if myString.utf16Count == 0. So if you’re going to perform a lot of those tests, it starts to matter. For a zero length string of “”, 100000 comparisons on my Mac mini took 0.015 seconds with utf16Count versus 0.04 for count(), a significant slowdown.

Turns out, however, that there’s an even better solution, which is to check whether the string is equal to “”. Nicolás Alvarez suggested this approach and I put it to the test, again running each comparison 100000 times. Results? Just 0.005 seconds to perform the == “” tests compared to 0.015 for the utf16Count ones.

Update: Davide De Franceschi asks, what about using .isEmpty. Answer: Not too shabby:

0.00494605302810669 // == ""
0.0156670212745667 // utf16count
0.0351709723472595 // count()
0.00633901357650757 // isEmpty

Update Alex Pretzlav adds, Your string counting question reminded me I had written this little guy:

func isEmptyOrNil<C : CollectionType>(x: C?) -> Bool { return x.map { isEmpty($0) } ?? true }

I like linear flows. With Cocoa calls, I request, check for failure, handle errors, and move on. The step-by-step results are easy to follow, to modify, and to understand many months later.

Quick note: 1.2 doesn’t seem to like the NSErrorPointer pattern I use in this post. You can easily replace with inout error : NSError?

NSString *StringFromURL(NSURL *url, NSError **error)
{
    // Request data
    NSData *data = [NSData dataWithContentsOfURL:url options:0 error:error];
    if (!data) return nil;
    
    // Convert the data to a UTF-8 string
    NSString *string = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
    if (!string) {
        if (error)
            *error = BuildError(1, @"Unable to build string from data");
        return nil;
    }
    
    // Return the string
    return string;
}

The standard Swift equivalent for these checks uses if-let constructs. If-let provisionally assigns a variable to the Some enumeration case. When the optional can be unwrapped, it’s assigned to a local non-optional variable (here, data and string) and used. The if-let else clause handles errors. Unfortunately, the success case tends to be buried in a pyramid of code extending above and below it. Here, the return string success appears smack in the middle of this function.

func StringFromURL(url : NSURL, error errorPointer : NSErrorPointer) -> (NSString?) {
    var error : NSError?
    
    if let data = NSData(contentsOfURL:url, options: NSDataReadingOptions(rawValue:0), error: &error) {
        if let string = NSString(data: data, encoding: NSUTF8StringEncoding) {
            return string
        }
        if errorPointer != nil {
            errorPointer.memory = BuildError(1, "Unable to build string from data")
        }
        return nil
    }
    if errorPointer != nil {
        errorPointer.memory = error
    }
    return nil
}

The following adaptation avoids the if-let pyramid, testing for nil cases instead of Some. It is wordier. It uses more variable declarations. But I rather like the clarity and readability and that the success case appears at the very bottom. I’d imagine this would be far easier to tweak and maintain especially if there are additional steps added at any future time.

func StringFromURL(url : NSURL, error errorPointer : NSErrorPointer) -> (NSString?) {
    var error : NSError?
    
    // Fetch data. Blocking.
    let data_ = NSData(contentsOfURL:url, options: NSDataReadingOptions(rawValue:0), error: &error)
    if (data_ == nil) {
        if errorPointer != nil {
            errorPointer.memory = error
        }
        return nil
    }
    let data = data_!
    
    // Convert to string.
    let string_ = NSString(data: data, encoding: NSUTF8StringEncoding)
    if (string_ == nil) {
        if errorPointer != nil {
            errorPointer.memory = BuildError(1, "Unable to build string from data")
        }
        return nil
    }
    let string = string_!
    
    return string
}

What do you think? Heresy? Approval? Drop a comment.