[swift-evolution] Adding Result to the Standard Library

[Xiaodi Wu]

On Thu, Nov 2, 2017 at 7:11 PM, Tony Allevato <tony.allevato at gmail.com>
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>
>
> 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.
>

Agree, issues such as this *must* be addressed for a successful `Result`
proposal. The resulting design should be highly coherent and reflect a
unitary vision of error handling; it cannot be merely a bolting-on of an
external Result type.


> 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/20171102/6b4e741f/attachment.html>