[swift-evolution] throws as returning a Result
dennis.s.lysenko at gmail.com
Mon Mar 14 10:39:02 CDT 2016
+1. The potential integration with auto-async-conversion here is brilliant
and will be incredibly useful if implemented.
On Mon, Mar 14, 2016 at 8:15 AM Thomas Guthrie via swift-evolution <
swift-evolution at swift.org> wrote:
> On 14 Mar 2016, at 11:36, Ondrej Barina via swift-evolution <
> swift-evolution at swift.org> wrote:
> it would be great usage of Result. (there was discussion about it. I
> think it was rejected).
> Not really sure about: "let a: Result<Foo> = makeFoo(42)"
> I can see that this could become more needed/used when we are going
> towards async coding in next Swift (4.0?).
> Result is mentioned in
> https://github.com/apple/swift/blob/master/docs/ErrorHandling.rst#manual-propagation-and-manipulation-of-errors (the proposal/doc
> for swift’s current error handling) and John McCall had this to say about
> We considered it, had some specifics worked out, and then decided to put
> it on hold. Part of our reasoning was that it seemed more like an
> implementation detail of the async / CPS-conversion features we’d like to
> provide than an independently valuable feature, given that we don’t want to
> encourage people to write library interfaces using functional-style error
> handling instead of throws.
> It’s also a feature that’s directly affected by the design of typed
> throws, which in turn poses some usability challenges for it. For example,
> without typed throws you really just want the type to be Result<T>. With
> typed throws, can you still write that, or do you have to write Result<T,
> ErrorType>? Also, if we want every function result signature to have a
> corresponding Result<> type, does that permanently prevent us to supporting
> multiple error types with “typed throws”? Also, would it be too
> frustrating to work with typed Result values if we don’t allow implicit
> covariant conversions along one or both dimensions?
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution