This morning, #swift-lang buzzed about multiple subscripts. “zOMG, you can have subscripts take more than one argument?” Why yes, yes you can. It’s a neat Swift trick, but a (pardon me) a tricky one.

For example, you might create an array and want to index it with foo[3, 5] or foo[7, 9]. Turns out that the general case is slightly trickier than I anticipated. The following demonstrates the desired indexing behavior.

let foo = [1, 2, 3, 4, 5, 6, 7]
println(foo[2]) // prints 3
println(foo[2, 4]) // prints [3, 5]
println(foo[2, 4, 1]) // prints [3, 5, 2]
println(foo[2, 4, 1, 5]) // prints [3, 5, 2, 6]

However, you don’t get this behavior out of the box.

Backtracking a little, you can easily build a custom subscript when you know a priori the number of elements you’re aiming for. For example, this extension returns two index items at a time. This is easy to implement and Swift can easily use parameter matching to figure out the overloaded results you’re aiming for.

// Two at a time
extension Array {
    typealias ArrayType = Element
    subscript(i1: Int, i2:Int) -> [ArrayType] {
        return [self[i1], self[i2]]
    }
}

It’s harder to extend this behavior for an arbitrary number of arguments. Specifically, you must take care with variadic arguments. The following approach won’t work.

subscript(i1: Int, i2:Int...)

Use that approach and you end up with infinite loops. That’s because Swift cannot distinguish this parameter declaration from an override of the standard single-item indexing. Variadic parameters accept zero or more values of a specified type, so  [2], [2, 4], [2, 4, 6], and [2,4, 6, 8] all match this declaration.

(Int, Int…) is virtually identical to (Int) at runtime, so Swift chooses this override to the original implementation for single-parameter lookups. That’s where the infinite loops come from. To make this work, you need a signature that won’t confuse swift. The proper solution uses two non-variadic arguments followed by a third variadic one, creating a “use this implementation for two or more parameters” scenario.

The following extension provides a final working solution. When you provide at least two subscript arguments, Swift knows to use this subscripting implementation.

extension Array {
    typealias ArrayType = Element
    subscript(i1: Int, i2: Int, rest: Int...) ->  [ArrayType] {
        var result = [self[i1], self[i2]]
            for index in rest {
                result += self[index]
            }
            return result
    }
}

Earlier this evening, a member of #iphonedev on Freenode needed to use the following function:

func rangeEnclosingPosition(_ position: UITextPosition!,
            withGranularity granularity: UITextGranularity,
                inDirection direction: UITextDirection) -> UITextRange!

The docs say that UITextDirection “can be of type UITextStorageDirection or UITextLayoutDirection.” but when you look this all up, you get:

enum UITextStorageDirection : Int {
    case Forward
    case Backward
}

enum UITextLayoutDirection : Int {
    case Right
    case Left
    case Up
    case Down
}

typealias UITextDirection = Int

As one member of the #swift-lang room put it, “‘My fault or Swift’s fault’ is a pretty frustrating experience.”

What to do? Lily B was able to suggest an immediate workaround by using UITextStorageDirection.Forward.toRaw(), and encouraged filing a radar.

Bigger lesson, especially taking yesterday’s language updates into account: Don’t write production code in a beta language, and make copious notes where you used work-arounds so you can re-address them later.

Today over at #swift-lang, a lively debate ensued over a hypothetical. What if Swift added arbitrary infix operators including Unicode. Would development be better served with operators like  the intersection operator (“∩”) over the current camelCode approach?

Some advantages are self evident. ∩ is a standard, mathematical representation. It’s widely accepted, widely used, and you’ll encounter it in most math textbooks. Plus it’s generic. It avoids mentioning a specific collection type, which would be required for selectors.

Despite this, I found myself arguing against (or at least against the overuse of) generic Unicode operators. While I welcome Unicode support in Swift, I see it best used to enable native language development. Unicode creates localized variables that make better sense than forced anglicizations. (Admittedly, I don’t see the point of cute dog-cow variables that show off language capabilities rather than enhance day-to-day development.) Even though this  operator is a decided win in the specific merits, I felt Unicode operators failed in the more general case.

I still experience occasional APL flashback nightmares.  The language wasn’t just a horrible experience in tracking down the right characters to create code. Once written, it was  virtually unintelligible even to those who had created those routines. Having experienced write-only code in the classroom, I’m not eager to return there in the app store.

Using Unicode operators incurs costs. As ∩ is not part of the standard first-level keyboard access, there’s a creation cost — both the mental overhead of remembering the operator to use as well as the hunt to find the character to enter.

Second, there’s a cost to readability from a cognitive recall/recognition standpoint. I admit the cost here is small since this particular operator is so well defined mathematically. But recognizing “intersectionWithSet” surely will map better to some people than recalling what the ∩ operator does, even if you end up having to create a suite of specialized selectors. This example really depends on the individual’s training. As operators become more self-defined or esoteric, this cost will rise.

Third, there’s a symbolic representation cost. Outside of standard mathematical representations, there’s an organizational overhead involved in choosing and managing representation elements that camel case text avoids. While the intersection operator is well defined, more general operators won’t be. (One shudders at the possibilities of the “Pile of Poo” operator — except perhaps for release calls.)

Finally, there are sharing costs. Any non-ascii code places a burden on documentation and web sites, especially those that don’t offer copy-paste support. You might be especially proficient with & and similar, but not everyone in your organization will be

It’s not that these costs are unreasonable or that some operators aren’t natural fits, it’s that I’m not sure the benefits outweigh those costs when implemented as a whole. While I can argue the other way (put it into the hands of developers who surely will use this parsimoniously and appropriately), I find myself preferring the more textual solution even if both are available.

In Xcode beta 3, Swift’s half-closed range operator has changed from .. to ..<, adding a less-than-sign visually distinguish half ranges (up to but not including) from full ones (up to and including). The update enhances visual inspection, making a clear differentiation between half (..<) and full (…) ranges.

While I applaud the intent, I dislike the result.

I get how errors similar to those between assignment and equality operators (= and ==) might happen. But while the =/== operators act in distinct ways, the range operators are more closely related. They’re less likely to produce foundational mistakes, and easier to catch through normal inspection.

A few additional points:

• The new half range operator is ugly. It turns an elegant for i in 1..5 into a visually confusing 1..<5
• When used next to a 3-digit, it looks like ascii art: for i in 1..<3 println(“Love you!”)
• Even without 3-adjacency, the new operator looks like an upside down deranged duck ..<
• The new operator requires explicit escaping on the web. (Thanks Andrew Wagner)

I’ve filed a radar. If you feel the same, consider adding one too.

As a final note, while this language tweak looks a bit like a literal duck, some are comparing it to the Coding Horror metaphorical one.

You may have noticed that, to date, Swift playgrounds are not the most stable. (You may add jokes here about the San Andreas Fault and your ex-significant-others.)  I often find myself copying items to command-line projects for testing.

Playgrounds offer the built-in results gutter to help determine when classes, structs, and functions are built and testing properly. With a command-line app, print statements replace single item evaluations. I prefer to do so in a way that doesn’t require tedious edits. Enter the postfix print operator.

operator postfix *** {}
@postfix func *** <T:Printable>(object : T) -> T {
    println(object.description)
    return object
}

What this operator gets me is something that I can easily use to convert items to print statements without editing to both the left and right. I can replace

myValue

with

myValue***

It also enables me to use a global find and replace to comment out the prints, replacing them with a sandbox-style declaration.

myValue //***

Nearly everyone I’ve shown this to reacts with noticeable horror, but I rather like its utility.