About a week ago, Chris Eidhof posted this in response to my JSON parsing blogs. Essentially, it's a functional approach at parsing JSON and solving the problem in a slightly different way.

Chris is very familiar with the ins and outs of functional programming, and if you are not as adept as he, you might look at this implementation and feel a bit lost and asking yourself, "uh… how is this easier?". I'll try to walk through it a bit more and apply the pattern to my strongly-typed JSON library.

Part of the confusion I see a lot with functional programming examples is simply this: they often fail to show the ugliness of the code they are fixing. Even with the nice, strongly-typed JSON library, you will still end up with code that looks like this:

extension Blog {
    static func parse(json: JSON?) -> FailableOf<Blog> {
        if let json = json {
            if let id = json["id"].number {
                if let name = json["name"].string {
                    if let needspassword = json["needspassword"].bool {
                        if let url = json["url"].string {
                            let blog = Blog(
                                id: Int(id),
                                name: name,
                                needsPassword: needspassword,
                                url: NSURL(string:url))
                            return FailableOf(blog)
                        }
                    }
                }
            }
        }

        let error = Error(code: 101, domain: "com.kiadsoftware.json", userInfo: nil)
        return FailableOf(error)
    }
}

Note: I'm using a type FailableOf<T> that I wrote about here: Error Handling in Swift.

: .info

The code kinda sucks.

Ok, it really sucks.

But since every access into the JSON data can gives us JSValue.Invalid, we need to guard against it. So there isn't really much more we can do from an imperative coding stand-point to make this better, especially given Swift's if-let construct for optional values.

Now, there is something that is lacking from Chris' implementation: validation of the JSON structure itself. Chris' implementation is not actually a JSON parser, it's a dictionary parser with some JSON semantics. That's a problem because there is no validation of the data that is going in and coming out can properly be transported as JSON in the next steps of our program (storing the NSURL as an object, integer overflow, etc…).

So, I think we can merge the two worlds and make something a bit more usable while still having complete validation of the JSON structure.

Givens

1. The strongly typed, parsed JSON data:

let json: JSON = [
  "stat": "ok",
  "blogs": [
    "blog": [
      [
        "id" : 73,
        "name" : "Bloxus test",
        "needspassword" : true,
        "url" : "http://remote.bloxus.com/"
      ],
      [
        "id" : 74,
        "name" : "Manila Test",
        "needspassword" : false,
        "url" : "http://flickrtest1.userland.com/"
      ]
    ]
  ]
]

2. The Blog structure we want to store the data in:

struct Blog {
    let id: Int
    let name: String
    let needsPassword : Bool
    let url: NSURL
}

3. The desire for full error information captured throughout the JSON parsing and Blog creation.

Approach

Now, we already have a pretty decent way to get an actual raw blog item:

let blog = json["blogs"]["blog"][0]

NOTE: We do not need a "functional" way to parse the JSON structure, though that would be an interesting topic for another day, as JSON is our type that we are going to be processing in a functional manner.

: .info

What we need though, is the ability to take that last dictionary and turn it into our Blog structure.

First, let's start out by adding some functional helpers to the JSValue class and putting the full FailableOf<T> construct in place. I've also update the members on JSValue to return FailableOf<T> instead of Optional<T> (e.g. json["id"].number now returns FailableOf<Double>).

func string(value: FailableOf<JSValue>, key: String) -> FailableOf<String>
func string(value: FailableOf<JSValue>, index: Int) -> FailableOf<String>
func number(value: FailableOf<JSValue>, key: String) -> FailableOf<Double>
func number(value: FailableOf<JSValue>, index: Int) -> FailableOf<Double>
func bool(value: FailableOf<JSValue>, key: String) -> FailableOf<Bool>
func bool(value: FailableOf<JSValue>, index: Int) -> FailableOf<Bool>

These provide us some handy helpers for pulling out an item from a dictionary or array from a JSON structure. These helpers also make it much easier to work with FailableOf<JSValue> and Optional<JSValue> types as there is no need for our usage code to check the error states; these methods simply chain that information back to the caller.

Next, let's start out by making our imperative solution somewhat better. For that, we need to move away from init() methods and into static creation methods that can return our error type: FailableOf<T>.

If Swift ever allows us to return error information on init(), then we can move away from static creation methods. Until then… we do what we have to.

: .info

This looks like this:

static func create(id: FailableOf<Int>,
    name: FailableOf<String>,
    needsPassword: FailableOf<Bool>,
    url: FailableOf<NSURL>) -> FailableOf<Blog>
{
    if let error = id.error {
        return FailableOf(error)
    }

    if let error = name.error {
        return FailableOf(error)
    }

    if let error = needsPassword.error {
        return FailableOf(error)
    }

    if let error = url.error {
        return FailableOf(error)
    }

    let blog = Blog(
        id: id.value!,
        name: name.value!,
        needsPassword: needsPassword.value!,
        url: url.value!)
    return FailableOf(blog)
}

This is already much better than what we had for our init() methods, though I'm not a fan of forcing the value out with id.value! and the others. The alternative, however, is more nesting.

The usage would look like:

let int: FailableOf<Int> = FailableOf(Int(number(json, "id").value!))
let url: FailableOf<NSURL> = FailableOf(NSURL(string: string(json, "url").value!))

let blog = create(
    id: int,
    name: string(json, "name"),
    needsPassword: bool(json, "needsPassword"),
    url: url)

Ok, this is still somewhat cumbersome. One of the issues is dealing with conversions from one type to another, for instance, converting from a Double to an Int. We could provide an int overload on JSValue, but that seems to be mixing our JSON parsing with our Blog parsing. So let's create a function coalesce to do the job for us:

func coalesce<T, U>(input: FailableOf<T>, convert: T -> U?) -> FailableOf<U> {
    if input.failed {
        return FailableOf(input.error!)
    }

    if let converted = convert(input.value!) {
        return FailableOf(converted)
    }
    else {
        let message = "Unable to convert value from type T to type U."
        let error = Error(
            code: 0,
            domain: "com.kiadsoftware.failable",
            userInfo: [LocalizedDescriptionKey: message])
        return FailableOf(error)
    }
}

Note that this function, coalesce is essentially equivalent to the >>= operator that Chris used, though his implementation differed because of some structural choices. We can do the same and it looks like this:

func >>=<T, U>(input: FailableOf<T>, convert: T -> U?) -> FailableOf<U> {
    return coalesce(input, convert)
}

So let's take a look at how things are shaping out now:

let blog = create(
    id: number(json, "id") >>= Blog.toInt,
    name: string(json, "name"),
    needsPassword: bool(json, "needsPassword"),
    url: string(json, "url") >>= Blog.toURL)

This is starting to look really good now. Just to recap what we have so far:

1. A functional way to get out values from a JSValue backed by a dictionary or array
2. A graceful way to convert those values, while maintaining the FailableOf<T> error state, to a value of any type.

At this point in the excercise, I'm pretty happy with what we have. But, we can still go one more step into the land of curried functions and partial function application like Chris showed; so let's do it. After all, what's the point in number() if we were going to stop here.

Curried Functions

Chris created a set of curry functions that he built up to allow him to parse out the JSON structure. That's one way to build up the function. Another is to simply let the compiler do it for us:

static func make(id: FailableOf<Int>)
                (name: FailableOf<String>)
                (needsPassword: FailableOf<Bool>)
                (url: FailableOf<NSURL>) -> FailableOf<Blog>
{
    if let error = id.error { return FailableOf(error) }
    if let error = name.error { return FailableOf(error) }
    if let error = needsPassword.error { return FailableOf(error) }
    if let error = url.error { return FailableOf(error) }

    return FailableOf(Blog(id: id.value!, name: name.value!, needsPassword: needsPassword.value!, url: url.value!))
}

That is our curried make function that we'll be using as the creation method for our Blog structure. Notice the multiple sets of (); that is how Swift knows this is a curried function. You can read more here.

Next, we are going to create that nice operator that Chris' made (he used <*>) in order to chain these together in a beautifully functional way, though, I'm a sucker for unicode operators, so I'll be using: ‚áí

infix operator ‚áí { associativity left precedence 150 }
func ‚áí <A, B>(lhs: (A -> B)?, rhs: A?) -> B? {
    if let lhs = lhs {
        if let rhs = rhs {
            return lhs(rhs)
        }
    }

    return nil
}

First, I want to call out that there is no use of FailableOf<T> here as this is a completely generic curry operator. In fact, this entire section has been generically applicable thus far.

This is the code we want to write in the end:

let blog = make ‚áí (number(json, "id") >>= Blog.toInt)
                ‚áí string(json, "name")
                ‚áí bool(json, "needspassword")
                ‚áí (string(json, "url") >>= Blog.toURL)

Remember that our curry operator returns an B? so to use that nicely parsed blog type, you will have to unwrap it.

if let blog = blog {
    // Blog is actually a FailableOf<Blog> now.
}

Extra Deep Dive

I want to point out something now that there is curried function support above: the >>= and ‚áí operators are almost identical. Take a look again:

func >>=<T, U>(input: FailableOf<T>, convert: T -> U?) -> FailableOf<U>
func ‚áí <A, B>(lhs: (A -> B)?, rhs: A?) -> B?

Both operators are really just transforming one item to another, the only real difference is which side the transformation function sits on. Instead of calling our ‚áí operator the "currying" operator we called it the "apply" operator, we can remove the >>= and reduce our operators down to a single one: ‚áí.

func ‚áí <A, B>(lhs: (A -> B)?, rhs: A?) -> B? {
    if let lhs = lhs {
        if let rhs = rhs {
            return lhs(rhs)
        }
    }

    return nil
}

func ‚áí <A, B>(lhs: A?, rhs: (A -> B)?) -> B? {
    if let lhs = lhs {
        if let rhs = rhs {
            return rhs(lhs)
        }
    }

    return nil
}

This allows us to write the following code instead:

// Change Blog.toInt to the following implementation:
static func toInt(number: FailableOf<Double>) -> FailableOf<Int> {
    if let error = number.error {
        return FailableOf(error)
    }

    return FailableOf(Int(number.value!))
}

// Change Blog.toURL to the following implementation:
static func toURL(string: FailableOf<String>) -> FailableOf<NSURL> {
    if let error = string.error {
        return FailableOf(error)
    }

    return FailableOf(NSURL(string: string.value!))
}

let blog = make ‚áí (number(json, "id") ‚áí Blog.toInt)
                ‚áí string(json, "name")
                ‚áí bool(json, "needspassword")
                ‚áí (string(json, "url") ‚áí Blog.toURL)

Ok, we are almost there now! Remember that stupid unboxing of the Optional<FailableOf<Blog>> we had to do above? Well, with a couple more operator overloads, that problem goes away as well.

public func ‚áí <A, B>(lhs: A -> B, rhs: A) -> B { return lhs(rhs) }
public func ‚áí <A, B>(lhs: A, rhs: A -> B) -> B { return rhs(lhs) }

Now the blog in the code above will simply be of type: FailableOf<Blog>.

So there we have it… a completely functional way to write a parser the JSValue type. I think this neatly merges both worlds. And, there is full error reporting support as well.

Again, just to show where we went from to where we ended up, take a look here:

// Before we went functional
static func parse(json: JSON?) -> FailableOf<Blog> {
    if let json = json {
        if let id = json["id"].number.value {
            if let name = json["name"].string.value {
                if let needspassword = json["needspassword"].bool.value {
                    if let url = json["url"].string.value {
                        let blog = Blog(
                            id: Int(id),
                            name: name,
                            needsPassword: needspassword,
                            url: NSURL(string:url))
                        return FailableOf(blog)
                    }
                }
            }
        }
    }

    return FailableOf(Error(code: 101, domain: "com.kiadsoftware.json", userInfo: nil))
}

// After we went functional
static func fparse(json: JSValue?) -> FailableOf<Blog> {
    return make ‚áí (number(json, "id") ‚áí Blog.toInt)
                ‚áí string(json, "name")
                ‚áí bool(json, "needspassword")
                ‚áí (string(json, "url") ‚áí Blog.toURL)
}

Resources

The full source for the JSON parser can be found here: https://github.com/owensd/json-swift.

The full source for the sample app is below. Simply copy it into a project and link the json-swift project.

import Foundation
import JSONLib

struct Blog {
    let id: Int
    let name: String
    let needsPassword : Bool
    let url: NSURL
}

func printBlog(blog: FailableOf<Blog>)
{
    if let blog = blog.value {
        println("id: \(blog.id)")
        println("name: \(blog.name)")
        println("needspassword: \(blog.needsPassword)")
        println("url: \(blog.url)")
    }
    else {
        let message = blog.error!.userInfo[LocalizedDescriptionKey]
        println("Error parsing blog: \(message)")
    }
}

var json: JSON = [
    "stat": "ok",
    "blogs": [
        "blog": [
            [
                "id" : 73,
                "name" : "Bloxus test",
                "needspassword" : true,
                "url" : "http://remote.bloxus.com/"
            ],
            [
                "id" : 74,
                "name" : "Manila Test",
                "needspassword" : false,
                "url" : "http://flickrtest1.userland.com/"
            ]
        ]
    ]
]

extension Blog {
    static func parse(json: JSON?) -> FailableOf<Blog> {
        if let json = json {
            if let id = json["id"].number.value {
                if let name = json["name"].string.value {
                    if let needspassword = json["needspassword"].bool.value {
                        if let url = json["url"].string.value {
                            let blog = Blog(
                                id: Int(id),
                                name: name,
                                needsPassword: needspassword,
                                url: NSURL(string:url))
                            return FailableOf(blog)
                        }
                    }
                }
            }
        }

        return FailableOf(Error(
            code: 101,
            domain: "com.kiadsoftware.json",
            userInfo: nil))
    }

    static func fparse(json: JSValue?) -> FailableOf<Blog> {
        return make ‚áí (number(json, "id") ‚áí Blog.toInt)
                    ‚áí string(json, "name")
                    ‚áí bool(json, "needspassword")
                    ‚áí (string(json, "url") ‚áí Blog.toURL)
    }
}

extension Blog {
    static func make(id: FailableOf<Int>)
                    (name: FailableOf<String>)
                    (needsPassword: FailableOf<Bool>)
                    (url: FailableOf<NSURL>) -> FailableOf<Blog>
    {
        if let error = id.error { return FailableOf(error) }
        if let error = name.error { return FailableOf(error) }
        if let error = needsPassword.error { return FailableOf(error) }
        if let error = url.error { return FailableOf(error) }

        return FailableOf(Blog(
            id: id.value!,
            name: name.value!,
            needsPassword: needsPassword.value!,
            url: url.value!))
    }

    static func toInt(number: FailableOf<Double>) -> FailableOf<Int> {
        if let error = number.error {
            return FailableOf(error)
        }

        return FailableOf(Int(number.value!))
    }
    static func toURL(string: FailableOf<String>) -> FailableOf<NSURL> {
        if let error = string.error {
            return FailableOf(error)
        }

        return FailableOf(NSURL(string: string.value!))
    }
}

printBlog(Blog.parse(json["blogs"]["blog"][0]))
println("--------------")
printBlog(Blog.fparse(json["blogs"]["blog"][0]))

There has been much talk on the dev forums about the lack of protected in the Swift language. My personal opinion? I do not like the protected construct nor do I think it fits with Swift's other access modifiers as it would then be the only class-scoped access modifier.

Anyway, I have been playing around with how we can mimick one of the key desires: limiting the public API scope.

WARNING: This solution is very much an experiment to see if what it might be like. Do not take this as something you should do in your code. USE AT YOUR OWN RISK.

: .warning

Ok… the basic premise of the idea is this: subclasses should be able to have full access to a set of data within a class. However, we to make make it "hard" for general consumers of the API to use it.

public class Vehicle {
    // This is how we "hide" the API from the general user.
    public class Protected {
        public var numberOfAxles: Int = 0
        public init() {}
    }
    public private(set) var protected: Protected = Protected()

    public init() {}

    // All us to copy the protected state down the inheritance chain
    public init(protected: Protected) {
        self.protected = protected
    }

    // Our first addition to the inheritance model
    public var numberOfWheels: Int {
        assert(false, "This should really be abstract")
        return 0
    }
}

Alright, this is pretty straight-forward. I have created an inner class that presents the protected data for the vehicle and exposed all of that through a single, public member: protected. So we have "polluted" our public API with a single item instead of multiple and make it clear (by convention) that this is an unsafe area to be in.

Let's add some cars now:

public class Car : Vehicle {
    public class ProtectedCar : Vehicle.Protected {
        public var wheelSize: Int = 14
        public init() {
            super.init()
            self.numberOfAxles = 2
        }
    }

    public init() {
        super.init(protected: ProtectedCar())
    }

    override public var numberOfWheels: Int {
        return 4
    }

    public func wheelSize() -> Int {
        return (self.protected as ProtectedCar).wheelSize
    }
}

public class SportsCar : Car {
    public init() {
        super.init()
        (self.protected as ProtectedCar).wheelSize = 18
    }
}

The Car class has some additional protected data, so I created another inner-class that inherits from Vehicle.Protected. I also created a true public API that retrieves some of that inner data: wheelSize().

And here are the test cases to see it in action:

func testCar() {
    let car = Car()
    XCTAssertEqual(car.protected.numberOfAxles, 2)
    XCTAssertEqual(car.numberOfWheels, 4)
    XCTAssertEqual(car.wheelSize(), 14)
}

func testSportsCar() {
    let car = SportsCar()
    XCTAssertEqual(car.protected.numberOfAxles, 2)
    XCTAssertEqual(car.numberOfWheels, 4)
    XCTAssertEqual(car.wheelSize(), 18)
}

func testSportsCarAsCar() {
    let car: Car = SportsCar()
    XCTAssertEqual(car.protected.numberOfAxles, 2)
    XCTAssertEqual(car.numberOfWheels, 4)
    XCTAssertEqual(car.wheelSize(), 18)
}

func testSportsCarAsCarToFunction() {
    func inner(car: Car) {
        XCTAssertEqual(car.protected.numberOfAxles, 2)
        XCTAssertEqual(car.numberOfWheels, 4)
        XCTAssertEqual(car.wheelSize(), 18)
    }

    let car: Car = SportsCar()
    inner(car)
}

func testSportsCarAsVehicleToFunction() {
    func inner(vehicle: Vehicle) {
        XCTAssertEqual(vehicle.protected.numberOfAxles, 2)
        XCTAssertEqual(vehicle.numberOfWheels, 4)
    }

    let car = SportsCar()
    inner(car)
}

If you are of the mindset that the protected construct is one that is rare and really is about setting boundaries for your developers to not accidently call your APIs that are really not intended for non-subclass types, then this inner-type methodology might be OK for you.

Will I be using this pattern? Probably not. But, it is an initial experiment that I'm sure others may want to improve upon if the protected construct never comes and there is no other alternatives.

With Xcode 6, Beta 4, we saw the introduction of access modifiers (maybe a better name is visibility modifiers). In essense, they control the visibility of the member throughout the module and outside of the module.

Here they are:

• private specifies an item that is available only within the context of the file
• internal specifies an item that is available only within the context of the module (e.g. the compiled target)
• public specifies an item that is available only both within the module and to all modules that import the given module

My personal opinion here… I'm not sure. I like the simplicity, but I think I'd simply rather have private and public. Seems Brent Simmons agrees. Time will tell, as will further Xcode 6 seeds.

The question naturally arrises: how do I test private methods?

Well, we have three basic options:

1. You don't and only test their usage through public APIs 2. You need to expose them publicly 3. You need to add the source to your test project so that they are part of the module and make then internal

Option #3 is the way that I'm currently doing it. Is it the best way? Probably not, but it does have the following advantages:

• We can selectively choose while files to add test coverage for
• There is no duplication of code signatures to maintain
• It works under both debug and ship builds
• There is no impact to the public API surface

Getting Started

To get started, simply create a new project that contains both a Swift target and a Swift XCTest target.

Next up, create a new Swift file. I created one called Person.swift.

I'll use this dummy class implementation:

public class Person {
    private var firstName: String
    private var lastName: String

    init(_ firstName: String, _ lastName: String) {
        self.firstName = Person.ensureValidName(firstName)
        self.lastName = Person.ensureValidName(lastName)
    }

    internal class func ensureValidName(name: String) -> String {
        if countElements(name) == 0 {
            return "<invalid name>"
        }
        else {
            return name
        }
    }
}

In this contrived example, we want to validate the function ensureValidName without actually invoking the initializer. Why might we want to do this? Well, simple: this function could be used in many different places in the API. For instance, we could put this in the setter implementation for firstName and lastName.

In order to test this method, we need to actually add Person.swift as a compile target to the XCTest target as well. Once you do that, the following test case will be valid:

import Cocoa
import XCTest
class TestingInternalsTests: XCTestCase {
    func testInvalidNameWithEmptyString() {
        XCTAssertEqual(Person.ensureValidName(""), "<invalid name>")
    }

    func testInvalidNameWithNonEmptyString() {
        XCTAssertEqual(Person.ensureValidName("David"), "David")
    }
}

There are a couple of drawbacks that we get with this approach:

1. We really are breaking the semantic rules here with respect to private and internal; there is no good reason that internal should be used for this function, except to expose it to tests. 2. We are compiling the Person.swift into the XCTest target; this could get messy as your project gets larger and larger.

As always, use with caution and with care. Hacks are hacks for a reason.

Update, August 22nd, 2014: Please see Error Handling – Take Two for some updated insights. It may be the case that named tuples are the right approach to solve this problem.

: .info

Error handling is something that seems to be have been left to the coder to figure out for Swift. Yes, there is the overly clunky and terribly awkward NSError usage:

func contentsForType(typeName: String,
                        error: NSErrorPointer) -> AnyObject!
{
    // some code, oops! an error
    if error {
        error.memory = NSError(domain: domain,
                                 code: code,
                             userInfo: [:])
    }
    return nil
}

That is terrible. Not only do we need to use the NSError class and jump over into the ObjC runtime, for absolutely no good reason, we get to use a terrible syntax that is not how Swift even wants you to work. At the very least error could be an inout reference and we can do something nicer…

Well, I think we can do better: we can borrow from other languages! Haskell has a concept of an Either type that is essentially "either this value or that". That's pretty much want we want: "either our return value or an error". Great! Let's implement that and see how it feels in Swift.

Let's start out with some requirements:

1. Need to support error information for function calls that have no return value
2. Need to support error information for function calls that return a value
3. Pure Swift implementation
4. Names that clearly identify what we are working with

With those requirements, we know that we are going to need three different items:

1. Error ‚Äî ‚Ääa type that represents the error information. This will simply be modelled after the NSError type

2 Failable ‚Ää‚Äî ‚Ääa type that represents either the error state or a success state with no return value

1. FailableOf<T> ‚Äî ‚Ääa type that represents either the error state or a success state with a return value

The Error class is the easiest and most straight-forward:

struct Error {
  typealias ErrorInfoDictionary = Dictionary<String, Any>

  let code: Int
  let domain: String
  let userInfo: ErrorInfoDictionary

  init(code: Int, domain: String, userInfo: ErrorInfoDictionary?) {
    self.code = code
    self.domain = domain
    if let info = userInfo {
      self.userInfo = info
    }
    else {
      self.userInfo = [String:Any]()
    }
  }
}

There really is not much to say about the class: it is basically the Swift version of the NSError class from ObjC.

Now, to tackle the Failable type:

enum Failable {
  case Success
  case Failure(Error)

  init() {
    self = .Success
  }

  init(_ error: Error) {
    self = .Failure(error)
  }

  var failed: Bool {
    switch self {
    case .Failure(let error):
      return true

    default:
      return false
    }
  }

  var error: Error? {
    switch self {
    case .Failure(let error):
      return error

    default:
      return nil
    }
  }
}

An enum is the perfect choice for us because a Failable has exactly two states: Success and Failure. There are no other possibilites.

On top of that, we have some helper methods failed and error that prevent us from having to write this terrible code to get the values out each time:

switch result {
case .Failure(let error):
  // handle the error here

default:
 // no error, do something else
}

Instead, we can write much more natural code:

let result = failableMethod()
if result.failed {
  // handle the error
}
// continue on

I'm going to pause here. Some of you may be wondering, why not implement the LogicValue protocol? Great question! Because that protocol is the DEVIL!

if result {
 // handle the error?? or does this mean there is a result???
}
// continue on?

I find the protocol extremely ambiguous and error prone. That's why I'm not using it.

The FailableOf<T> is not that much different, other than a fairly annoying bug in Swift that cannot generate the correct code—more on that in a minute.

enum FailableOf<T> {
  case Success(FailableValueWrapper<T>)
  case Failure(Error)

  init(_ value: T) {
    self = .Success(FailableValueWrapper(value))
  }

  init(_ error: Error) {
    self = .Failure(error)
  }

  var failed: Bool { /* same as above … */ }
  var error: Error? { /* same as above … */ }

  var value: T? {
    switch self {
    case .Success(let wrapper):
      return wrapper.value

    default:
      return nil
    }
  }
}

There are a few changes:

1. A value is stored for the Success state
2. A new value property has been added
3. There is this pesky FailableValueWrapper

There is a bug in Swift where the compiler cannot generate the code for an enum that does not have a fixed layout, which would be the case if the Success value could hold any old type of T. To get around this, we can create a wrapper class so that the FailableOf<T> can essentially use the class pointer size for laying about the enum. Hopefully this gets addressed in later drops.

That's basically it. Now we can handle errors in a much more Swift-friendly way. Below is some sample use case:

func failWhenNilAndReturn(name: String?) -> FailableOf<T> {
  // not using .Success because of the
  // FailableValueWrapper workaround.
  if let n = name { return FailabeOf<T>(n) }
  else { return .Failure(Error(code: 2,
                              domain: "err",
                            userInfo: nil)) }
}

let result = failWhenNilAndReturn("David")
if result.failed { /* handle the error */ }
println("name: \(result.value!)")

I'm not the first to write on this topic, nor will I be the last. This is definitely an odd area that was left out for Swift…

The full source code can be found in my SwiftLib project on GitHub: https://github.com/owensd/SwiftLib.

If you've been following along with Swift, you would have noticed some very interesting semantics with arrays: they were completely broken! Interestingly enough, there were many people arguing in the forums and other places that this was "ok" and "good for performance".

Fortunately for us, the Swift team decided on sanity. So instead of code like this working (Xcode 6, Beta 2):

let array = [5, 1, 0, 10]
array[1] = 0   // just changed a value in the "const" array, ok…
array += 5     // compile time error: good

var sortedArray = sort(array)   // original array updated, oops!
sortedArray.append(4)

sortedArray                     // prints: [0, 0, 5, 10, 4]
array                           // prints: [0, 0, 5, 10]

We can return to the world of sanity in Xcode 6, Beta 3:

let array = [5, 1, 0, 10]
array[1] = 0      // compile time error: good
array += 5        // compile time error: good

var sortedArray = [Int](array)
sortedArray.sort(<)
sortedArray.append(4)

sortedArray                // prints: [0, 1, 5, 10, 4]
array                      // prints: [5, 1, 0, 10]

Many late-nights of debugging arrays have just been saved. Now, all we need, is a way to express const on class types. =)

When looking at how to design and structure our own code, it's often best to start with what exists in the language and platform that we are working in. So, when it's time to design a new type, such as a SortedArray or Set, how would we implement this in Swift?

I'm guessing that your first thought is to inherit the Array class and override the insertion methods and indexing setter (unless you're already familiar with Swift…). However, that will not work because the Array class in Swift is not a class at all, it is a struct. There has been much discussion about this on the developer forums and I also wrote about some of my concerns with them already, but most of that was with the broken semantics of arrays with the let construct; I did not see much in the context of the problems with extensibility.

There is a good argument that this is bad example as the APIs are slightly different between an Array and a Set class, but the metapoint still stands.

: .info

If we look at the Swift documentation, this is what we learn about structs, or rather, the benefits of classes over structs:

Classes have additional capabilities that structures do not:

• Inheritance enables one class to inherit the characteristics of another.
• Type casting enables you to check and interpret the type of a class instance at runtime.
• Deinitializers enable an instance of a class to free up any resources it has assigned.
• Reference counting allows more than one reference to a class instance.

I've bolded the part that is going to limit us in our design choices. We really only have two options available to us now:

1. Composition 2. A new implementation

Neither of these approaches is ideal because they require significantly more code than the inheritance choice we should have had.

This goes back to my original thoughts on Swift and one of the foundational aspects of Objective-C: extensibility. When I referenced that, I was not talking about the extensibility of the ObjC language, but rather, the extensibility of every type in the system.

Swift, at it's heart, seems to be going against that at fundamental level. The two biggest pieces of evidence for this are the the following:

1. Every type we have seen thus far in the Swift Standard Library has been declared as a struct. Interestingly enough, many are also backed by internal class types. 2. The introduction of the @final construct to specifically prevent inheritance and extending the functionality of class types

So what is the take-away when foundational types of the language that are classic examples of types that should be classes are implemented as structs? To me, it seems the API designers for Swift are already compensating for weaknesses in the language's runtime and are trading supposed run-time performance over platform extensibility and that we, as developers of frameworks, should be doing the same.

If you read my previous piece on JSON Parsing in Swift, things looked really drab. And in fact, if you try to use Swift straight-up to do it, it still sucks. However, while trying to make this experience better, I stumbled across one very interesting feature of Swift that helped me create a very light-weight JSON library that gives me all of the expressiveness I had with ObjC while keeping true to the semantics of Swift.

In ObjC, we are able to express JSON as a literal construct made up of the various Foundation types. There was a land-mine waiting if you didn't use the right types, such as NSData, with properly encoding them first, but it was possible to do and the syntax was great. In Swift, a semantic JSON blob might look like this:

var json = [
  "stat": "ok",
  "blogs": [
    "blog": [
      [
        "id" : 73,
        "name" : "Bloxus test",
        "needspassword" : true,
        "url" : "http://remote.bloxus.com/"
      ],
      [
        "id" : 74,
        "name" : "Manila Test",
        "needspassword" : false,
        "url" : "http://flickrtest1.userland.com/"
      ]
    ]
  ]
]

That is semantically what we want and Swift will happily allow us to shove that into an NSDictionary or Dictionary<String, AnyObject>. My fear was that creating a "real" version of this in Swift would require manually boxing the types, and that sucks! And then I stumbled upon a truly awesome feature of Swift. Seriously, it's sweet!

Introducing Convertibles

Convertibles allow you to specify ways to convert most of the literals into a different type by implementing a protocol. Let's take a look at an example:

class MyDoubleDouble : FloatLiteralConvertible {
    var double : Double

    init(_ value: Double) {
        double = value * 2
    }

    class func convertFromFloatLiteral(value: Double) -> MyDoubleDouble {
        return MyDoubleDouble(value)
    }
}

let double = 2.0                        // double has a value of 2.0
let myDouble : MyDoubleDouble = 2.0     // myDouble.double has a value of 4.0

Ok. Things just got really interesting now. We can extend this to nearly all of the literal types, including dictionaries and arrays. So we can actually keep the terse and expressive syntax from above if we simply annotate the type for the JSON value:

var json : JSON = [ ... ]

With that one type annotation of JSON (defined in my library), that code gets created in a fully type-safe JSON structure. That is pure gold.

Indexing the Goods

Retrieving the data from within the JSON is just as easy as well. If we overload the subscript methods for strings and integers, we can provide full dictionary and array lookups that are type-safe and conform to the semantics of Swift's optional typing.

A quick example of grabbing the blog ID from the first blog in the structure.

if let blogId = json["blogs"]?["blog"]?[0]?["id"]?.number {
  println("blog ID: \(blogID)")
}

In The End

With just a little bit of work (and a lot of time fighting with current bugs in Xcode and Swift), Swift makes it possible to toe the line between type-safety and expressiveness. I can only imagine, that when we get proper documentation for all of this goodness, that most of my static typing concerns will simply dissapear.

Feeling much more bullish on Swift today. =)

Full Source for the JSON project is here: https://github.com/owensd/json-swift/.

Update June 21st: I've fixed the errors of my ways: JSON Parsing Reborn. The content of this article still holds if you use straight-up Swift, but Swift provides us with a much better way to improve this.

: .info

In my previous article, I got some flack about many things, including JSON parsing and how the Swift code is no worse because of the generics. Here's an example of why I think it is worse. If any of the code is incorrect or if it could be written better, let me know and I'll update accordingly. Maybe I'll be proven wrong and that I just need to do it a different way and the problems go away. If that's the case, that would great.

Here is the JSON that we will be parsing:

{
  "stat": "ok",
  "blogs": {
    "blog": [
      {
        "id" : 73,
        "name" : "Bloxus test",
        "needspassword" : false,
        "url" : "http://remote.bloxus.com/"
      },
      {
        "id" : 74,
        "name" : "Manila Test",
        "needspassword" : true,
        "url" : "http://flickrtest1.userland.com/"
      }
    ]
  }
}

Both the ObjC code and the Swift code works under the following conditions (that is, it prints nothing when invalid or prints the blog entries when valid; also, it does not crash):

1. The JSON response is nil
2. The JSON response is an unexpected type, such as an array or string
3. The JSON response does not have the blogs key
4. The JSON response has the blogs key, but not the blog key
5. The JSON response has the keys, but blog is the wrong type
6. The JSON response has the keys and correct type, but blog is empty
7. The JSON response has the keys, the correct types, and data in blog, but missing some keys (such as id or name)
8. The JSON response is fully filled out

Here is the ObjC code that is needed to safely parse the code:

if ([json isKindOfClass:[NSDictionary class]]) {
    NSDictionary *dict = json[@"blogs"];
    if ([dict isKindOfClass:[NSDictionary class]]) {
        NSArray *blogs = dict[@"blogs"][@"blog"];
        if ([blogs isKindOfClass:[NSArray class]]) {
            for (NSDictionary *blog in blogs) {
                if ([blog isKindOfClass:[NSDictionary class]]) {
                    NSLog(@"Blog ID: %@", blog[@"id"]);
                    NSLog(@"Blog Name: %@", blog[@"name"]);
                    NSLog(@"Blog Needs Password: %@", blog[@"needspassword"]);
                    NSLog(@"Blog URL: %@", blog[@"url"]);
                }
            }
        }
    }
}

Here is the Swift code to do the same.

if let dict = json as? NSDictionary {
    if let blogs = dict["blogs"] as? Dictionary<String, AnyObject> {
        if let blogItems : AnyObject = blogs["blog"] {
            if let collection = blogItems as? Array<AnyObject> {
                for blog : AnyObject in collection {
                    if let blogInfo = blog as? Dictionary<String, AnyObject> {
                        let id : AnyObject? = blogInfo["id"]
                        let name : AnyObject? = blogInfo["name"]
                        let needspassword : AnyObject? = blogInfo["needspassword"]
                        let url : AnyObject? = blogInfo["url"]

                        println("Blog ID: \(id)")
                        println("Blog Name: \(name)")
                        println("Blog Needs Password: \(needspassword)")
                        println("Blog URL: \(url)")
                    }
                }
            }
        }
    }
}

I wrote unit tests for both Swift and ObjC to validate the claims I made above; both sets of code run without crashing under the error conditions and print the output successfully.

Both sets of code have to do similar checks to validate the types, but the Swift code is cluttered with meaningless type annotations. Also, the retrieval of items out of the dictionaries seems more complicated than it needs to be. Maybe I'm simply doing something wrong…

Of course, this isn't the canonical use of JSON. Really, the ObjC version of the code should actually boil down to this:

for (NSDictionary *blog in json[@"blogs"][@"blog"]) {
  NSLog(@"Blog ID: %@", blog[@"id"]);
  NSLog(@"Blog Name: %@", blog[@"name"]);
  NSLog(@"Blog Needs Password: %@", blog[@"needspassword"]);
  NSLog(@"Blog URL: %@", blog[@"url"]);
}

Why? Simple: when dealing with JSON, the structure is well-defined as we are simply parsing out the results.

The simplest I could get the Swift code was this:

let dict = json as Dictionary<String, AnyObject>
let blogs : AnyObject? = dict["blogs"]?["blog"]
let collection = blogs! as Array<Dictionary<String, AnyObject>>
for blog in collection {
  let id : AnyObject? = blog["id"]
  let name : AnyObject? = blog["name"]
  let needspassword : AnyObject? = blog["needspassword"]
  let url : AnyObject? = blog["url"]

  println("Blog ID: \(id)")
  println("Blog Name: \(name)")
  println("Blog Needs Password: \(needspassword)")
  println("Blog URL: \(url)")
}

All of the type gymnastics is off-putting, especially since it conveys no meaning and reduces the clarity of the code significantly. The bigger the JSON blob to parse, the more this issue is exasperated.

Note that you need AnyObject? to remove the compiler warnings.

Update: June 18th

I was asked on twitter by @jtjoelson why I didn't use typed dictionaries if I knew the schema. Well, I didn't think it helped the code. Here are two versions using fully typed information based on the JSON schema.

let dict = json as Dictionary<String, Dictionary<String, Array<Dictionary<String, AnyObject>>>>
let blogs = dict["blogs"]!["blog"]!
for blog in blogs {
  let id : AnyObject? = blog["id"]
  let name : AnyObject? = blog["name"]
  let needspassword : AnyObject? = blog["needspassword"]
  let url : AnyObject? = blog["url"]

  println("Blog ID: \(id)")
  println("Blog Name: \(name)")
  println("Blog Needs Password: \(needspassword)")
  println("Blog URL: \(url)")
}

Of course, we can make that monster of a type look better with typealiases.

typealias Blog = Dictionary<String, AnyObject>
typealias BlogCollection = Array<Blog>
typealias BlogsDictionary = Dictionary<String, BlogCollection>
typealias FlickrResponse = Dictionary<String, BlogsDictionary>

let dict = json as FlickrResponse
let blogs = dict["blogs"]!["blog"]!
for blog in blogs {
  let id : AnyObject? = blog["id"]
  let name : AnyObject? = blog["name"]
  let needspassword : AnyObject? = blog["needspassword"]
  let url : AnyObject? = blog["url"]

  println("Blog ID: \(id)")
  println("Blog Name: \(name)")
  println("Blog Needs Password: \(needspassword)")
  println("Blog URL: \(url)")
}

The type information is certainly more legiable. But really, the only choice from here to make this more readable and filled with less type info is to create classes to represent all of this and parse the values yourself. That's a lot of code to write for very little value.

The ObjC code will throw an exception if the schema is invalid. I can catch that exception and log it, but there is little error recovery that I can really do at the point. The rigid class will have to ultimately do the same thing, or report an error status of some kind. In ObjC, I had to write far less code and more readable code than I did in Swift to arrive at the same outcome: failed parsing or correct output.

It has only been weeks since Swift was announced, and it is only the first drop of Swift that the public has seen. At the same time, we are only a matter of months away from the nebulous "Fall" timeframe for when the Swift language will essentially hit v1.0 with the final drop of Xcode 6.

This has me very sad for the future of iOS and OS X development. I do not see, at this point in time, any major changes happening to Swift. There are many fundamental items about Swift that I'm just not a fan of and I think break the spirit of what ObjC was about: pragmatism.

These are the items that I think truly represent the heart of ObjC:

1. Dynamic Typing
2. Message Passing
3. Extensibility (at runtime)
4. Protocols (aka Interfaces)

The rest of the features of ObjC are really just implemented on these ideals. With the advent of Swift, we see these as the ideals:

1. Static Typing 2. Generics 3. Dispatch tables 4. Extensibility (at compile time)

Gone is the dynamic nature of ObjC; it has instead been replaced by a rigid, generic based type system. I know the world of C

I do not think we got "ObjC without the C", rather, we got something much more like C# that compiles on clang and bridges into Cocoa a bit haphazardly.

ObjC without the C

I'm going to break down some examples of what I would have liked to have seen in Swift instead of what we got; I'll refer to that version of Swift as SwiftOC (or Swift with ObjC).

Generics

Let's start off with everyone's favorite canonical example of why we need generics: a collection of items.

In Swift, we can create strongly-typed collections:

let intArray = [1, 2, 3, 4]        // Array<Int>
let stringArray = [ "hi", "bye" ]  // Array<String>
let array = [ 3, 4.5, 8.9 ]        // NSArray, not! Array<Double>

Ok, in our imagined SwiftOC, we could have had the same code, but each type would have simply been an Array:

let intArray = [1, 2, 3, 4]        // Array
let stringArray = [ "hi", "bye" ]  // Array
let array = [ 3, 4.5, 8.9 ]        // Array

But what if I put in a wrong type? I hear this argument a lot… and well, yes, it is a possibility. It is also the possibility to put in an incorrect value, to be off by one iterating over the array, or to print the contents of the wrong array; there's a line somewhere that needs to be drawn where the programmer needs to figure out how to address potential issues in ones code. However, this is a case that is immediately found at run-time; it is not a pandemic problem that needs the rigidity of generics to solve.

What about the generic functions like sort?

func sort<T : Comparable>(array: T[]) -> T[]
func sort<T>(array: T[], pred: (T, T) -> Bool) -> T[]

That is what sort looks like today. Notice a truism about generics that often gets overlooked: all generics require a contract for the types to work; sometimes this is explicit, other times it's implicit and only inferred at compile time. It is also easy to overlook the fact that this contract is often implemented via overloaded operators, which hides the details away making it look like you get certain functionality for free—I call this "compiler magic".

In SwiftOC sort would have looked like this:

// Comp would be a Comparable interface, shortened for space reasons
func sort(array: Array) -> Array
func sort(array: Array, pred: (Comp, Comp) -> Bool) -> Array

I'll admit, there is a difference between the SwiftOC code, and, yes, the Swift version is technically more type-safe, on paper at least. The difference is that in Swift you can guarantee that each item in the array adheres to the Comparable protocol.

This is where theory and practice comes in to play though. This is fundamentally not a real-world problem that gets exposed for any length of time, if at all; it is caught early, even in a project with little-to-no testing. It's a classic compile-time vs run-time tradeoff.

Further, you could actually still implement this in a collection class if you wanted by enforcing the add methods to require the inserted items to implement Comparable.

class Array {
  func insert(#item: Comparable, atIndex: Int) {}
}

There you go, all items that go into the array meet the requirements of sort. In fact, you could require and provide a default behavior for all types within the language and provide default behaviors for particular types. This again would alleviate most of the problems that were trying to be solved with generics in the above example.

Yes, generics can be useful in particular cases. However, they are not helpful, ironically, in the generic use case. I would argue that simply sticking with a stronger-type base instead of fully type-safe and generic based language would have been a more pragmatic route to take.

Let's take a look at another example where generics really are not helpful: JSON.

var resp = {
  "stat": "ok",
  "blogs": {
    "blog": [
      {
        "id" : 73,
        "name" : "Bloxus test",
        "needspassword" : 0,
        "url" : "http://remote.bloxus.com/"
      },
      {
        "id" : 74,
        "name" : "Manila Test",
        "needspassword" : 1,
        "url" : "http://flickrtest1.userland.com/"
      }
    ]
  }
}

That's a real-world JSON response from a web-services API. Note the mix of strings and numbers; even if they were all strings, they are only string representations of a number.

Swift's type-safety mechanics offer absolutely no help here. In fact, we really need to use the Cocoa types to do anything useful with this because what we have is an untyped dictionary: Dictionary<String, AnyObject!> or NSDictionary. In order to write safe code here, you have to do the exact same thing in either language: check for a null value and check for a value that can be converted to the expected type.

let blogs = resp["blogs"]?["blog"]  // ? could be done in both Swift
                                    // and SwiftOC

At the end of the day, there are essentially two worlds of programming languages when it comes to types: static and dynamic. The Apple platform and the entire web platform have run on dynamic code with relatively little problems because of the type system. However, in one move, I believe Apple did the biggest disservice to ObjC programmers: fundamentally shifted them from a world of flexibility to a world of rigidity based on the guise of "safety" and generic programming.

Simplicity

ObjC was a fairly simple language—it added on a few, well defined mechanics of top of already concise language: C. There were virtually no special rules to apply to different parts of the language. However, with Swift, we are opened up to the world of complexity. Yes, the syntax is concise and fairly easy to grasp, however, you are entering a world that is deceptively simple.

let optval : Bool? = false
if optval           { "1" }
if optval!          { "2" }
if optval == false  { "3" }
if optval! == false { "4" }
if optval == true   { "5" }
if optval! == true  { "6" }

What happens in the above code? Yes, this is a trick question and a source of some discussion on the developer forums. The answer is this:

"1"
"3"
"4"

The reason? Well, optional values can be implicitly compared to non-optional values thanks to this overloaded operator:

func ==<T : Equatable>(lhs: T?, rhs: T?) -> Bool

So that check to see if your optional value has a value or not better not use the == operator; if so, you'll end up with the wrong results. This is extremely error prone and very hard to track down because you cannot actually debug the flow to understand what is going on here; these are compiler choices not run-time decisions you can see on the stack—more "compiler magic".

Operator overloading is often cited as a powerful, if not good, addition to any language. However, it can be the source of some of the most non-obvious programming errors and is far worse then non-generic typed arrays. When the incorrect values show up in the array, things go boom quick. When these types of errors happen, they are subtle, sporadic, and often hard to repro without the exact set of data that went into the failing code path.

Let's look at another:

var intValue = 2
var doubleValue = 1.1

func add(x: Int, y: Int) -> Int { ... }
func add(x: Double, y: Double) -> Double { ... }

add(intValue, doubleValue)

Which function gets called?

If you answered, neither, you are correct! Because of Swift's type-safety, neither of these are valid. This could be a good thing such that no numbers are coerced improperly to different types, but pragmatically, this results in code that should look like this:

let radius = 4
let pi = 3.14159
var area = pi * radius * radius

Into code that looks like this:

let radius = 4
let pi = 3.14159
var area = pi * Double(radius) * Double(radius)

That's not simpler and I would argue adds no safety, but rather, detracts from what the code is supposed to really be doing. Sure radius could have been a double, but it's not always the case that one is performing math operations on the same types of values.

Also in the above is method overloading. This is relatively safe, but does promote the loss of intention from the functions. If we had:

func add(x: Int, y: Int) -> Int { ... }
func add(s1: String, s2: String) -> String { ... }
// the operator version
func +(x: Int, y: Int) -> Int { ... }
func +(s1: String, s2: String) -> String { ... }

What is the string version supposed to do? Parse the numbers from the string and return string representation of the result? Append the string? It would be much clearer to instead choose better names:

func append(string: String, to: String) -> String { ... }

This is much clearer, especially since the named parameters are part of the signature. Swift seems to be moving away from this though, especially in the context of items like overloading operators. I do not think that is a good thing. It's also against part of what has made Cocoa such a good framework to work with: self documenting code.

Syntax and Style

This is an area that I think Swift did a fairly decent job on. It's cleaner, in most cases more straight-forward, and offers some helpful shortcuts for various patterns.

There is one thing that I would have actually like Swift to address: curly braces.

Curly braces have long been the source of discussions, or rather, "holy wars". What line do they belong on, which level of indentation do they get, do we use them for one-liners? Swift had a perfect opportunity to absolve this problem by simply removing them from the language. The truth of the matter is that we simply do not need them anymore. Also, it would have imposed a style on the language that would have enforced consistently across codebases which would have only increased readability and pattern matching.

func compare(x: Int, y: Int) -> Int {
  if x < y { return -1 }
  else if x > y
  {
    return 1
  }
  else
    {
    return 0
    }
}

That's the kind of mixture of braces that we've all seen. And sometimes in the same code file! YUCK! I think Swift would have gained a lot if it took a page out of Python's book:

func compare(x: Int, y: Int) -> Int
  if x < y
    return -1
  elseif x > y
    return 1
  else
    return 0
  end
end

Sure, the end keywords are not actually necessary for a parser. However, they provide visual clarity to the end of blocks. Whitespace does an insufficient job at this, especially when scanning code quickly. But if we want to be purists, then we would have this:

func compare(x: Int, y: Int) -> Int
  if x < y
    return -1
  elseif x > y
    return 1
  else
    return 0

Of course, both should not be supported. I do think that either one would have been preferable though.

Summary

I think there is a lot more to discuss about the language and how I think Apple has missed the mark of "Objective-C without the C". Instead, it really fells like we got a form of C# 2.0 or the core of the C

Unfortunately, I do not think that much of this will change with later drops. Instead, we'll see bug fixes and refinements of what exists today. It is very un-Apple to drop such a huge and fundamentally different change on our laps as they have been the company of evolutionary refinement.

There is no doubt in my mind that Swift will win over many, but will they be from the long-time Apple developer crowd or will they be the converts from the Android and Windows world? ObjC has long been a misunderstood language to them because many were unwilling to really embrace the paradigm. Apple seems to have bent to their will instead of providing us with a truly great ObjC 3.0. This saddens me greatly.

Chris Lattner (@clattner_llvm, the guy behind the Swift language), said this about the language on Twitter:

Swift is a pragmatic, not a religious, language. It tries to get the defaults right, but allows you to change them if it doesn't suit you.

: .quote

I have to wonder, what is the pragmatic goal of Swift? From where I sit, it's gets all of the defaults wrong because the defaults should have been about the interaction with the Cocoa API. Until there are native Swift versions of those, all of code looks and feels much messier and far less elegant than what we have today.