Justin Spahr-Summers

Result allows you to treat errors like Plain Old Values, and pass them around with static type information, for easy introspection.

@jspahrsummers Async should be manageable by mapping throws->T to ->Either<ErrorType,T> and back. Static propagation checking ensures it.

@jckarter ErrorType is a pretty useless construct on its own, though. Makes the Either useless except as a vehicle for it.

@jspahrsummers You can match out the cases you can recover from. Exhaustive error handling is rare; more specific types wouldn't help much.

@jckarter I disagree. For example, ReactiveCocoa uses a NoError type to statically guarantee the absence of errors.

@jckarter You can’t do that by treating everything as ErrorType.

@jspahrsummers How is that different from using a nonthrowing function, or returning non-Either?

@jckarter Signal<T, Error> is parameterized by the type of error it can send. If you use NoError, it cannot be instantiated.

@jspahrsummers (an earnest question, there may be, just seems like a super rare feature)

@paulcbetts Haskell. But, more to the point, exceptions are the worst, and adding them to Swift is a mistake.

@jspahrsummers maybe? If ARC can unwind the alloc'd objs on the way out it might not be bad

@paulcbetts That’s not why I dislike exceptions. They’re just a magical “blessed” control flow construct embedded into the language.

@paulcbetts I prefer monadic chaining or similar stuff.

@jspahrsummers @olebegemann Swift errors are not exceptions.

@gparker @olebegemann I understand the intricacies. Doesn't change my point.

@jspahrsummers @olebegemann Is there a problem with passing ErrorType values around as Plain Old Values?

@gparker @olebegemann It makes recovering the concrete implementation harder (namely, impossible to do statically).https://twitter.com/jspahrsummers/status/608070247841722369 …

@jspahrsummers @olebegemann But is it bad enough to prevent async use, for example? (I thought capture/rethrow was OK but haven't tried it.)