[swift-evolution] Adding Result to the Standard Library

[Tony Allevato]

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>

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> 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)
> 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
>>
>>
> _______________________________________________
> 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/20171103/37151396/attachment.html>