The tricky part of this approach comes when you extend it. Let's say we have two functions and we'd like to combine them and return a third. typealias Hand

The tricky part of this approach comes when you extend it. Let's say we have two functions and we'd like to combine them and return a third. typealias Handler1 = (Result<Data, LoadError> -> Void) typealias Handler2 = (Result<Address, IndexError> -> Void) func load(addr: Address, then handler: @escaping Handler1) { ... } func lookup(name: string, then handler: @escaping Handler2) { ... } // What would the type of Handler3 be? func loadDefault(then handler: @escaping Handler3) { lookup("default") { result in switch result { case .success(let address): load(address) { result2 in switch result2 { case .success(let data): // Happy path case .failure(let error): // We have a load error for handler3 } case .failure(let outerError): // ERROR: We have a lookup error for handler3 } } } // P.S., don't complain about syntax I really don't know swift :P Handler3's type is actually the sum of LoadError and IndexError. This is sort of a non-trivial problem for a lot of use cases of Either. Monadic and Railway Either programming typically solve this problem by saying, "Fine well then every single Either/Result in the chain needs to be of the same type, which includes a unified error type." In this article's case, I guess we could appeal to Swift's binding to FoundationKit to lift up NSError? Sure! That'll compile! Maybe there is a Compound Type thing? It will probably compile but it'll shape your handler in weird ways. It still seems pretty unsatisfying. The point here was to make it easy to work out what errors we should handle, but now we need an explosion of combination types (unique to each call graph in this case, wow!) Modern Haskell, which along with ML pioneered these style of, has some slick type machinery tricks to deal with this that are not well supported yet (even type lists are not a slam dunk because we need something that's order-insensitive). Most folks will be required to make a new ad-hoc sum type (like Result, but EitherError<Error1, Error2>), and then have to pattern match on that to handle errors. But at the end of the day, even Haskell with all its principle has try/catch statements in IO and an exception hierarchy. In fact, it's considered best practice for production code to avoid giving the appearance that Either can capture all your errors (since it seldom can): https://www.fpcomplete.com/blog/2016/11/exceptions-best-practices-haskell https://www.fpcomplete.com/blog/2016/11/exceptions-best-prac... Which is not to say Either's (and Railway programming's) "Sum-type errors") aren't a substantial improvement over special return values or Common Lisp/Go's product-style return values. They are. But sadly they can't really get you away from exception handling when you start interacting with the "real" world as the examples here do. It's a win for things like HTTP responses or decoding libraries.