try! Swift Tokyo 2018 #tryswiftconf

No content

let trySwift = .success(!)

let trySwift: Result??> = .success(!)

Result V.S. Result 2018/03/08 try!Swift Tokyo 2018 After talks Yasuhiro Inami / @inamiy

// Without error type parameter public enum Result { case success(Value) case failure(Swift.Error) } // V.S. // With error type parameter public enum Result { case success(Value) case failure(Error) }

No content

No content

Result (V.S. Result) • GOOD • Can contain error "type" (not only error "value"!) • Represents error domain (where error comes from) • Exhaustive error pattern matching • BAD • mapError is required per error domain switching • Nested enum errors

What BAD people say: "There is no need to check errors exhaustively" "To check a specific error, just using as? casting is sufficient"

What GOOD people say: Error type is NOT just for error handling

NoError Uninhabited (empty) error type

What is NoError ? • enum NoError: Swift.Error {} • Can't create value (e.g. Never) • NoError is also an Error • Represents "0" of algebraic data type • Zero (bottom) type enriches type representation

// Example: ReactiveSwift UI Binding // (Can be used ONLY WHEN `Error == NoError`) static func <~ ( provider: Self, source: Source ) -> Disposable? where Source.Value == Value, Source.Error == NoError { ... } // Binding let alphaSignal: Signal = ... view.reactive.alpha <~ alphaSignal

Usage of NoError • Signal • Observable type that never errors out • No need to create another type, e.g. RxSwift.Driver • Result • Represents succcessful value only (Can't be described using Result) • Shouldn't we just use plain Value instead? → NO!

Result Value If we have a function of Observable -> Result (e.g. ReactiveSwift.first): In Result world... extension SignalProducer { public func first() -> Result? { ... } }

In Result world... extension SignalProducer { // This `self` may error out, so we use `Result?` public func first() -> Result? { ... } } extension SignalProducer where Error == NoError { // This `self` will NEVER errors out (by `where` constraint), // so we don't want to use `Result?` here! public func first() -> Value? { ... } } Different type signature = meaningless overload !"

Mathematically speaking... • Result Value • Not exactly the same, but isomorphic (invertible) • For more info, dive to Category Theory • NoError is "0" • Useful for non-error handling, which is also a part of error handling! • Result / Observable are the world without zero

Swift Poem: Why I prefer typed error https://gist.github.com/inamiy/ e3f5f7524f1bcdc582c2ff8dbbba58dd

let trySwift: Result??> = .success(!)

let trySwift: Result = .success(!)

Thanks! Yasuhiro Inami @inamiy