[CookWithMe]

Nice article, well done!

Minor question/comment regarding the implementation of Result.map: Why do you create a new Result in the error case? Result is immutable (or am I missing something specific to Swift here?), so the old and new Result are the same and stay that way.

I'm not familiar with the internals of Swift, but e.g. in Scala, there is only one "None". If you call map or flatMap on it, the same None will always be returned.

[DanWaterworth]

I'm not familiar with swift, but in Haskell, you can't write the following:

    flatMap :: Either e a -> (a -> Either e b) -> Either e b
    flatMap x f =
      case x of
        Left _ -> x
        Right x' -> f x'

In the case expression, you have to write `Left err -> Left err`, because `x` here has the type `Either e a`, but `Either e b` is expected.

[JSoto]

Yeah, this is correct. This would be wrong:

    func map<U>(f: T -> U) -> Result<U> {
        switch self {
        case let .Value(value):
            return Result<U>.Value(Box(f(value.unbox)))
        case let .Error(error):
            // self is Result<T>, but the return type must be Result<U>
            return self
        }
    }

[josephlord]

enums and structs are value types (and Result is an enum) so I think that you could just return self for the error case (gaining cleanliness and a little efficiency).

Objects (of classes) are reference types so if Result was a class there would be a difference between returning self and returning a new Result.

[JSoto]

I agree that it would be a little cleaner, because it would express the intention better (the fact that you're simply giving out the same error). However, the type would be wrong:

Yeah, this is correct. This would be wrong:

    func map<U>(f: T -> U) -> Result<U> {
        switch self {
        case let .Value(value):
            return Result<U>.Value(Box(f(value.unbox)))
        case let .Error(error):
            // self is Result<T>, but the return type must be Result<U>
            return self
        }
    }

As for efficiency: like you mention, enum are value types. For this reason, they're passed by copy! So even returning self would return a copy of self, not the same instance :)

[CookWithMe]

Yep, you are right.

I looked deeper into the Scala implementation of Option [1] to see how Scala achieves that, and whether I can port their implementation to Swift.

Long story short: Scala has a bottom type [2], Swift does not, therefore the Scala-implementation can not be ported to Swift.

A bit more detail: In Scala, Some and None are not enum-Values (as in Swift), but there is an abstract class called Option which Some and None inherit from. Option is a generic class. None is not generic anymore (this alone isn't possible in Swift!), but is an Option[Nothing]. Nothing is the bottom type: it can be returned for any Option[U], because Nothing "inherits" from all classes, and therefore also from U.

OK, that was still pretty short - if anyone is interested in a longer write-up including code, please let me know and I'll write a blog post :-)

[1] https://github.com/scala/scala/blob/838ff2c2f256d1c114a406ff...

[2] http://en.wikipedia.org/wiki/Bottom_type

[josephlord]

Good point. I missed that. Trouble with reading blog posts is getting relevant bits of code together on the screen, should have opened a second browser window (or third to include the HN discussion).

Value types are actually copy on write internally in Swift so no copy will be done unless a mutation of the error is attempted.

[JSoto]

Oh yeah that's a good point! (and a really interesting optimization that can be applied to immutable values)