[swift-evolution] [proposal] Either in the Swift Standard Library

[Matthew Johnson]

> On Jan 28, 2016, at 12:33 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Thu, Jan 28, 2016, at 10:13 AM, Chris Lattner wrote:
>> FWIW, I’m in favor of typed throws, but only of a single type that conforms to ErrorType.    “throws” would be sugar for “throws ErrorType”.  The most common case I would imagine people using is “throws SomeEnum”.  I’m personally not interested in supporting “throws A,B”.
> 
> That seems like a very sensible approach to take. We'd want to figure out some way to make it convenient to coerce some typed error into another typed error that "contains" the first, so that way I can say something like
> 
> enum FooError: ErrorType { ... }
> 
> enum BarError: ErrorType {
>    case Foo(FooError)
>    // ...
> }
> 
> func foo() throws FooError {
>    // ...
> }
> 
> func bar() throws BarError {
>    try foo()
> }
> 
> and have the call to `try foo()` implicitly wrap the FooError in BarError.
> 
> Rust solved this by defining a trait std::convert::From that takes a type parameter and converts from that type parameter to Self (and every type T implicit implements From<T> so you can always convert from a type to itself). And its try!() macro passes all errors through convert::From::from(err), so if you have a "parent" error type that can contain a "child" error type, you just implement From<Child> on the Parent and now errors will get implicitly converted whenever the try!() macro is used. Of course, this relies on a few features that Swift doesn't have, and Swift's `try` is built into the language instead of being a standard library macro, but I can imagine that we might have some language support for similar behavior (heck, we could even make it so that any enum that conforms to ErrorType and has a variant with a single associated value that's another ErrorType will implicitly be able to convert from the child ErrorType to the parent ErrorType when calling a typed throwing method with try).

Support for converting Errors during propagation is something that would be extremely nice.  David Owens II and I had a pretty in-depth exchange about this in the thread on his proposal.  This should not be limited to error types that “contain” the underlying type as an associated value for a case.  It should support more general uses, such as converting from the error thrown by a library used in the implementation to an error exposed by your API contract (as is possible in Rust).

David showed how we can get do an ok job of this using ad-hoc overloading.  The big downside of that is that it is ad-hoc and there will be many variations on it throughout the community (as with Result).  It is also more verbose than actual language support would be.  It would be much better if a solution is part of the common vocabulary of the language.

-Matthew

> 
> -Kevin Ballard
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution