# SE-0235 - Add Result to the Standard Library

**URL:** <https://forums.swift.org/t/se-0235-add-result-to-the-standard-library/17752>\
**Category:** Proposal Reviews\
**Created:** [November 7, 2018, 10:32pm UTC](https://forums.swift.org/t/se-0235-add-result-to-the-standard-library/17752 "2018-11-07T22:32:55Z")\
**Posts on this page:** 1\
**Showing post:** 183

<div class="post-metadata">

**Author:** ![koher](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/koher/32/1222_2.png) [@koher](https://forums.swift.org/u/koher)\
**Post date:** [November 16, 2018, 5:35pm UTC](https://forums.swift.org/t/se-0235-add-result-to-the-standard-library/17752/183 "2018-11-16T17:35:27Z")

</div>

Although the review period is over, please let me leave my comment. I have been thinking about it for days.

If I correctly understood what you intended in the comment below you linked,

> [@Adding Result II: Unconstrained Boogaloo](https://forums.swift.org/t/adding-result-ii-unconstrained-boogaloo/17128/18):
>
> Referring back to @John_McCall's original [error handling rationale](https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst), I think `throws` and `Result` can be seen as addressing different corners of the design space. As the rationale describes, `throws` was designed for systemic errors, which tend to have a large distance between error source and error handler, so source and handler end up needing to be rather loosely coupled, which was a motivator for the exception-like propagation and lack of specific typing in the current `throws` feature. `Result` on the other hand is great for conditions that are intended to be immediately handled by the caller, for which being an regular return value with a more specific failure type is in fact the more convenient representation.

it seems to suggest that `JSONDecoder.decode(_:from:)` returns `Result`s instead of throwing errors.

I think usefulness of automatic propagation (`throws`) is not limited to "systemic errors". For example, if we have an API to decode JSONs manually, and if manual propagation (`Result`) is preferred for non "systemic errors", the API would return `Result`s like `JSONDecoder.decode(_:from:)`. Then decoding JSONs manually would be written like below with complex conversions.

```swift
func decodeFoo(from json: JSON) -> Result<Foo, DecodingError> {
    return Result {
        let a: Int = try json["a"].unwrapped()
        let b: Bool = try json["b"].unwrapped()
        let c: String = try json["c"].unwrapped()
        return Foo(a: a, b: b, c: c)
    }.mapError { $0 as! DecodingError }
}

```

If the API throws errors directly, it can be written much more simply as follows (assuming that [throwing subscripts](https://github.com/brentdax/swift-evolution/blob/throwing-properties/proposals/0000-throwing-properties.md) referred in [SE-0148](https://github.com/apple/swift-evolution/blob/master/proposals/0148-generic-subscripts.md) are available).

```swift
func decodeFoo(from json: JSON) throws -> Foo {
    let a: Int = try json["a"]
    let b: Bool = try json["b"]
    let c: String = try json["c"]
    return Foo(a: a, b: b, c: c)
}

```

As seen in the example above, I think automatic propagation is also useful for non "systemic errors". So I prefer using `Result` more limitedly as @John_McCall commented.

> [@John\_McCall](#):
>
> I want to clarify that I favor adding `Result` _only_ to address situations where manual propagation is necessary.

Then I think it is better not to add `Result` to the standard library _now_. If `Result` is added to the standard library now, I am sure that it will be widely abused instead of `throws`. I guess 90% of actual use cases of `Result` _today_ are for asynchronous operations and typed errors. Because `async/await` and typed throws are not supported currently, `Result` will be the only way for the cases. If `async/await` and typed throws are introduced first (though I am not sure if typed throws should be supported), before `Result`, `async/await` and typed throws would be used in the cases. And the community could get experienced with them. Then `Result` could be used properly only when manual propagation is required.

---

_[View the full topic](https://forums.swift.org/t/se-0235-add-result-to-the-standard-library/17752)._
