[swift-evolution] Adding Result to the Standard Library

[Dave DeLong]

> On Nov 2, 2017, at 6:19 PM, Dave DeLong <swift at davedelong.com> wrote:
> 
> 
> 
>> On Nov 2, 2017, at 6:11 PM, Tony Allevato via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Proposing syntactic sugar for this at the same time would go a long way toward making me less reluctant to support it. As a type by itself, I don’t think it holds its weight in the standard library.
>> 
>> The question that I’d want to see answered is, is it possible to make it so that these two functions are identical for all intents and purposes?
>> 
>> func foo() throws -> Int
>> func foo() -> Result<Int>
> 
> I mentioned this equivalency during the async/await debate: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170821/039196.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170821/039196.html>
> 
> I think this would be a great addition.

Additionally, Erica had some thoughts around how to make unwrapping even easier, which includes support for Result<T>:

https://gist.github.com/erica/aea6a1c55e9e92f843f92e2b16879b0f <https://gist.github.com/erica/aea6a1c55e9e92f843f92e2b16879b0f>

Dave

> 
>> 
>> Doing that at the call site is easy enough (the proposed implementation does much of that, but more could be done at the language level to remove the manual unwrapping), but I’m not sure how you reconcile the fact that, of those two declarations, an author *does* have to pick one to write.
>> 
>> One thing I can think of off the top of my head is forbid functions from returning Result<> but allow them to be created by assignment from a throwing function. That, however, seems like an arbitrary and just flat out bizarre limitation and I can’t really bring myself to support it.
>> 
>> I guess the problem I want to avoid is that, even if you sugar away all the differences between Result<> and throwing when it comes to *calling* these functions, there would still be two ways to declare essentially the same function, and the choice of which someone uses becomes arbitrary and meaningless.
>> 
>> On Thu, Nov 2, 2017 at 5:02 PM Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> This is clearly a fine addition to the standard library; even Swift's Error Handling Rationale (https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst <https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst>) 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 <mailto: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 <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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/c8219766/attachment.html>