[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)