Implicit Chaining and Context

If you’ve been following along, I’ve been struggling with the optional chaining syntax.

The Swift team has been fairly active in helping people with their troubles and confusion, and Chris Lattner responded to mine here (login required).

I won’t quote all of it (mainly because I don’t think I’m supposed to), but the gist of of it was this: if Swift supported implicit optional chaining, then it would be unclear which code was executed in the chain and which was not (this is my paraphrase, not Chris’ exact words).

An example:

No implicit chaining

my.delegate?.can().call()?.some(stuff())
foo.bar(baz())

With implicit chaining

my.delegate.can().call().some(stuff())
foo.bar(baz())

Chris’ argument is that with implicit chaining, the code above is ambiguous. In line #1, it’s explicit that there are many potential breaks along the code so it’s clear that everything to the right of a ? has the potential of not being called. For line #2, it’s clear there no breaks. However, with implicit chaining, lines #1 and lines #2 do not carry that information and it’s unclear if stuff() or baz() are ever called.

I understand his point; afterall, it is clear (in any editing/reading environment) that there are multiple failure (or maybe more accurately, short-circuiting) points along the way when we use ?. But, it still didn’t sit right with me.

I was asking myself why… I think I know why it didn’t sit well: I think the example is void of any and all context that could potentially already answer that question for us.

For example, if we know that Swift supports implicit optional chaining, then we already know that member lookups can potentially fail. Now, you might argue that I’ve simply made every member lookup ambiguous. But I don’t think that is the case either.

You see, the code samples above are all taken out of context. Code doesn’t live in isolation, but it participates in the context around it.

Here’s a snippet of code from a JSON tests:

func testValidateSingleValueNumberUsagePatternOptionalChaining() {
    var json: JSValue = 123

    let value = json.number?.distanceTo(100) ?? 0
    XCTAssertEqual(value, -23)
}

If I had written:

func testValidateSingleValueNumberUsagePatternOptionalChaining() {
    var json: JSValue = 123

    let value = json.number.distanceTo(100) ?? 0
    XCTAssertEqual(value, -23)
}

Or even:

func testValidateSingleValueNumberUsagePatternOptionalChaining() {
    var json: JSValue = 123

    let value = json.number.distanceTo(distanceToMoon()) ?? 0
    XCTAssertEqual(value, distanceToMoon() - 123)
}

The code carries no loss in value. Even without that the aid of coding tools, the ?? operator already tells me I’m working with a left-hand side that is Optional<T> and a righ-hand side this of type T. Context is also how I know that the type of value is Double (not an Int like you might be expecting) because JSValue.number holds a Double?.

I think it’s easy to take a code snippet, or worse, make up a line of code that also has no intrinsic meaning, and make a good case for why it has the potential to cause ambiguity. My argument is not that it’s not possible write ambiguous code with implicit chaining, but rather, that the context of your code ensures that the ambiguity is seldom, if ever, there.

In the end, I think it simply comes down to this:

Writing code is like writing in any language – often times we have constructs and words that look the same but are different, such as “I read a book yesterday” and “I read every morning”. The usage of “read”, when taking out of the context of its environment carries too little information to reveal its full meaning. However, once we provide the surrounding context, the meaning is made explicitly clear.

As a corrolary, we shouldn’t also then say that because I can write, “I read in the morning”, that the usage of “read” should not be allowed because it creates ambiguity: do I read every morning, or did I read this morning. Rather, we say that the sentence is ambiguous when taking out of its full context and we should add more context, or, if the statement is meant to stand on its own, make the disambiguate the meaning.

I think pragmatically, the use of Optional<T> is the same: context reveals the explicit meaning of the code.

Implicit Chaining and Context

The Case for Implicit Optional Chaining

Update #2, Chris Lattner has stated this isn't a good idea because it can lead to ambiguity in code that may have side effects, such as foo.bar(baz()). The question is, does baz() get called or not. With foo?.bar(baz()) it is clear that there is a potential for baz() to not get called.

I understand what he is saying, though, I'm not sure I'm in agreement yet. Anyhow, it's nice to have this dialoge with the fine folks on the Swift team.

: .info

I've been wrestling with the verbosity of Optional Chaining for quite some time now. It started with my first JSON Parsing article and really hasn't gone away since then. Much of the work there was done to explicity hide the fact that a lookup could fail. Why do we need that? The language already has a construct to help us with this: Optionals.

Here's the example code that's essentially in the Swift Programming Language guide linked above:

class Residence {
    var numberOfRooms: Int = 1
}

class Person {
    var residence: Residence?
}

var john = Person()
// john.residence = Residence()  // uncomment this to toggle with if-else branch you get

if let roomCount = john.residence?.numberOfRooms {
    println("John's residence has \(roomCount) room(s).")
} else {
    println("Unable to retrieve the number of rooms.")
}

The above, the lone ? isn't that big of a deal. Though, I do think it's superfluous.

Let's get the cat out the bag: Swift is all about type inference. We can seldom look at code out of context and reason the type that is store in any given variable. For instance, what is the type for numberOfRooms? It's like an Int, but it could be Int?, Double, a UInt, maybe an Int8, or whatever.

There is only way to know: look at the definition.

A handy way to do that: ‚å• + Click

Showing type interference for 'let roomCount' is Int?

However, I'm also going to assert this: we do know the type while we are authoring the code. We know because we are going to use it and we need to know. This is subtley different from above but just as important. The context we are in gives us clarity over what it is.

This is what I think the code should look like:

if let roomCount = john.residence.numberOfRooms {
    println("John's residence has \(roomCount) room(s).")
} else {
    println("Unable to retrieve the number of rooms.")
}

That's it, just remove the ?. Wait, doesn't that add confusion? How did numberOfRooms end up as an Int? requiring us to use if-let? Well, we know because at the time of authoring, we knew that residence is backed by Residence?. It doesn't matter when we come to modify the code how roomCount became an Int?, it only matters that it is one and you need to work with it as one.

The only time you will care why roomCount became an Int? is when you need to modify that variable itself, but then you are going to need to understand the entire chain john.residence.numberOfRooms at that point anyway. We've actually lost very little here and gained clarity in syntax.

Let's change the example above to contain a little richer data:

class RoomInfo {
    var description: String = ""
    var width: Double = 0
    var depth: Double = 0
}

class Residence {
    var rooms: [RoomInfo]? = nil
}

class Person {
    var residence: Residence?
}

var john = Person()

if let roomCount = john.residence?.rooms?.count {
    println("John's residence has \(roomCount) room(s).")
} else {
    println("Unable to retrieve the number of rooms.")
}

This is where things are string to get really ugly for me. Why are there two ?? Yes, I know that both residence and rooms are an Optional<T>, but I don't really care. The purpose of the code is this: retrieve the number of rooms at John's residence. The ? do not help me get there. Further, I'll add that if you really care about the ?, you should be checking for which of the items, residence or rooms is nil, but the simple truth is this: we do not actually care; we only care about the end result in the chain.

So, instead, simply make the code what we want:

if let roomCount = john.residence.rooms.count {
    println("John's residence has \(roomCount) room(s).")
} else {
    println("Unable to retrieve the number of rooms.")
}

The code above tells me one simple truth: when I get a roomCount, it's going to be an Optional<T>, because something down the chain failed; I do not care what failed, just that it failed and I'm going to handle that.

The code with the ?. tells me something different. It tells me that on your way to roomCount the members residence or rooms could have returned nil. I can get that info from the type declaration too, if I really wanted it. Don't make me repeat myself, especially when I'm doing so and it is not even important enough for me to do something about.

Update: August 13th, 2014

: .info

There was an interesting question asked about Optional<T> methods and extensions that collide with the type T. Here's an example (current Swift syntax; no implicit optional chaining):

extension Optional: Printable {
    public var description: String {
        return "a message for you"
    }
}

// Add the extension for String:
extension String: Printable {
    public var description: String {
        return "printable: string"
    }
}

let string: String? = nil
let s1 = string.description     // s1: String
let s2 = string?.description    // s2: String?

Today that is not ambiguous, we know which to call. With implicit chaining:

let string: String? = nil
let s1 = string.description

So, do we call the description on String or on Optional<T>?

I'm going to assert the following:

  1. We want to optimize for the non-Optional<T>; after all, that's why I want implicit chaining.
  2. The Optional<T> is already a special construct in the language and I'm ok with adding more rules in certain cases for when we need to deal with it directly as I think those cases are the exception, not the rule.

This means that I want the String.description version called.

If we really want the Optional<T> version, we have a way to do so:

let s1 = (string as Optional<String>).description

In the rare case where there is a collision, the compiler could do the following:

  1. Create an error or warning (I'd prefer a warning) that this is ambiguity, and
  2. Provide two "fix-it" options for the two valid cases for you to disambiguate, or
  3. Do nothing… I tend to think this is actually the right answer.

We could also (as mentioned by Wallacy Freitas on the devforums) simply invert the ? usage to treat it as explicitly working with the optional:

let s1 = string?.description

Again, I think this is simply an explicit example of the rare case. With the ? today, we need to always defend against this possibility. I would rather optimize for the normal case and provide a way around the corner case.

The Case for Implicit Optional Chaining

Functional JSON

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]))
Functional JSON

Fixed Enum Layout Sizes

WARNING: Turns out there are some nasty side-effects, see the update below.

: .warning

If you have every attempted to create a generic enum, you have most certainly encountered the following error message:

error: unimplemented IR generation feature non-fixed multi-payload enum layout

: .warning

Yikes! Well, it turns out that Swift (whether by-design or a current limitation) needs to know the full layout size of the enum at compile time. So code like this:

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

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

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

  var failed: Bool { /* ... */ }
  var error: Error? { /* ... */ }

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

    default:
      return nil
    }
  }
}

Is just not possible to write. I had worked around this by using a wrapper class FailableWrapper<T> (see Error Handling in Swift).

However, Rob Napier tweeted a much more elegant solution.

//platform.twitter.com/widgets.js
When I saw that, I thought, "well duh!". So much better than my workaround.

Here's the source for my full FailableOf<T> class; no more need for the wrapper class.

public enum FailableOf<T> {
    case Success(@autoclosure() -> T)
    case Failure(Error)

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

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

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

        default:
            return false
        }
    }

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

        default:
            return nil
        }
    }

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

        default:
            return nil
        }
    }
}

UPDATE August 6th: Thanks for John Vasileff for pointing out, what should have been, an obvious design flaw with this approach.

: .info

//platform.twitter.com/widgets.js
Yep… he's right. =)

Back to my wrapper class for now.

Fixed Enum Layout Sizes

How to protected your APIs

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.

How to protected your APIs

Testing Privates (or rather, internals)

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.

Testing Privates (or rather, internals)

Error Handling in Swift

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.

Error Handling in Swift

Swift Arrays are Fixed!

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

Swift Arrays are Fixed!

Swift and Inheritance

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.

Swift and Inheritance

JSON Parsing Reborn

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

JSON Parsing Reborn