[swift-evolution] Adding Result to the Standard Library

Xiaodi Wu xiaodi.wu at gmail.com
Thu Nov 2 19:01:44 CDT 2017

This is clearly a fine addition to the standard library; even Swift's Error
Handling Rationale (
mentions such an addition

What separates standard library types from other types is that they have
language level support, and the wrapping and unwrapping syntax here could
definitely benefit from it (`.unwrap()`--which should be `.unwrapped()`
incidentally--is so much less elegant in comparison to `?` and `!` for
optionals (not that `Result` should use the exact such syntax for a
distinct operation)). It would be a shame to transpose a third-party
`Result` to the standard library without considering if any such tweaks
would substantially improve ergonomics, interconversion with Optional and
throws, etc.

On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution <
swift-evolution at swift.org> wrote:

> Swift-Evolution:
> I’ve written a first draft of a proposal to add Result<T> to the standard
> library by directly porting the Result<T> type used in Alamofire to the
> standard library. I’d be happy to implement it (type and tests for free!)
> if someone could point me to the right place to do so. I’m not including it
> directly in this email, since it includes the full implementation and is
> therefore quite long. (Discourse, please!)
> https://github.com/jshier/swift-evolution/blob/master/
> proposals/0187-add-result-to-the-standard-library.md
> Thanks,
> Jon Shier
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171102/fe531d27/attachment.html>

More information about the swift-evolution mailing list