Sent from my iPad
> On Feb 19, 2017, at 11:34 AM, Brandon Knope via swift-evolution > <[email protected]> wrote: > > I really like this. Seems much more elegant and simple this way +1 > >> On Feb 17, 2017, at 4:45 PM, Joe Groff via swift-evolution >> <[email protected]> wrote: >> >> >>> On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution >>> <[email protected]> wrote: >>> >>> I suggest we need to find a way to shorten the list of the possible error >>> types with a the help of typeallias >>> >>> extension MyError1: Error { ... } >>> extension MyError2: Error { ... } >>> extension MyError3: Error { ... } >>> >>> typealias MyErrors = MyError1 | MyError2 | MyError3 >>> >>> func foo() throws(MyErrors) -> MyResult >>> func bar<T : Error>(_: () throws(T) -> Void) rethrows(MyErrors, T) -> >>> MyResult >> Do you actually need that? Experience in other languages like Rust and >> Haskell that use Result-based error propagation suggests that a single error >> type is adequate, and beneficial in many ways. If nothing else, you could >> `Either` your way to multiple errors if you really needed to. >> >> IMO, if we accept a single error type per function, there could be a simpler >> model for this. We could say that the `throws` type is a generic parameter >> of all function types, and it defaults to the uninhabited `Never` type for >> functions that don't throw. >> >> () -> () == () throws Never -> () >> () throws -> () == () throws Error -> () >> >> In this model, you'd get many benefits: >> >> - `rethrows` could become first-class, reducing down to just polymorphic >> `throws`: >> >> func foo(_: () throws -> ()) rethrows // Swift 3 >> func foo<T: Error>(_: () throws T -> ()) throws T // Swift X >> func foo<T: Error>(_: () throws T -> ()) throws Either<MyErrors, T> >> >> - Protocols could abstract over error handling; for instance, we could >> support throwing sequences: >> >> protocol IteratorProtocol { >> associatedtype Element >> associatedtype Error: Swift.Error = Never >> >> mutating func next() throws Error -> Element? >> } >> >> Separate of the type system model, the type *checking* model also deserves >> thorough consideration. Propagating the effects of possibly multiple error >> types propagating within a `do` block is much trickier than doing so as a >> single "throws" or not bit, especially if you want to be able to use type >> context in `catch` patterns or to implicitly propagate a narrower `throws` >> type out of the enclosing function. >> >> -Joe >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
