Programming Languages: Swift

With all the buzz about Apple's new Swift programming language for iOS to go along with Objective-C, I had to read the big thick manual they put out and several other bloggers' opinion pieces. It should come as no surprise that developers are pleased with Swift, since Objective-C is an aging language.

Right away, you should note that at this point in time you need XCode 6 to program in Swift. XCode 6 is still just in beta and only available on MacOS. When Microsoft came out with C#, one similarly could only program in C# using Visual Studio in Windows. Now, C# is also available in using the open source, cross-platform Mono development system. One can hope that something similar emerges for Swift down the road.

Swift comes out of the box with type inference, pattern matching, generics, closures/lambdas, hashes/dictionaries, tuples, and string interpolation. Many of these features have been added to languages such as Java, C#, and D either long after the programming language was introduced or via a runtime library API. The runtime library API approach never makes data structures like hashes and tuples feel quite the same as built-in support to parse literals of those types.

Optionals
A lot of fuss is made about Swift's support for "optionals." Such types are similar to F# options or the C# generic "Nullable" class. Again, Swift handles this with a built-in type rather than a library API class. As a built-in type, the ? and ! syntax for Swift optionals make them read more smoothly than an API, although not all that different than the F# discriminated union implementation of the same idea.

Pattern Matching
I'm fond of F#'s pattern matching (which comes with its roots in ML), and I'm really happy to see pattern matching in Swift both with tuples and enumerations with associated values. The Swift language definition doesn't use the words "pattern matching," but the bindings that happen when using the keyword combination "case let" in a switch statement cause the same kind of variable binding to occur while doing a successful control flow definition as with F#'s "match" statement.

Access Control
One criticism I read was that Swift didn't contain any support for access control with keywords like "public" or "private." The same can be said of JavaScript, but like JavaScript it doesn't seem like Swift should need a "private" keyword because it supports both constructors and closures. If one can nest the definition of a method inside the definition of a constructor, the method gets access to the local variables of the constructor. Like private data members in languages with a special keyword, these local variables can only be accessed by the nested member functions. Hence, this criticism would seem to be unfounded and based on a lack of understanding of how closures work.

Concurrency
A larger concern of mine would be the seeming lack of support for concurrency. Swift does not seem to support anything similar to the "synchronized" keyword in Java or C# or an API class supporting futures. Apple's devices are multi-core and even a single-core device with single threaded applications can benefit performance-wise from concurrency. It seems a shame that some kind of basic, limited support for concurrency isn't built into the initial design of a modern language.