[swift-evolution] Adding Result to the Standard Library

[T.J. Usiyan]

+1 from me… for what it's worth. The value, in my opinion, is that we won't
each have to add result. I would prefer Either<A,B> but I will take
Result<A>.

On Thu, Nov 2, 2017 at 2:35 PM, Dave DeLong via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Nov 2, 2017, at 12:32 PM, Jon Shier <jon at jonshier.com> wrote:
>
> That’s been an argument against Result for 2 years now. The usefulness of
> the type, even outside of whatever asynchronous language support the core
> team comes up with, perhaps this year, perhaps next year, is still very
> high. Even as something that just wraps throwing functions, or otherwise
> exists as a local, synchronous value, it’s still very useful as way to
> encapsulate the value/error pattern. That pattern will likely never go
> away. Additionally, having the Result type in the standard library removes
> a source of conflict between all other Result implementations, which are
> becoming more common.
>
>
> 👆 👏
>
> There’s a lot of stuff I’m tired of implementing myself while waiting for
> the the core team “to lay the ground for”. Result is up there near the top
> of my list too.
>
> Dave
>
>
>
> On Nov 2, 2017, at 2:26 PM, Tony Allevato <tony.allevato at gmail.com> wrote:
>
> Given that the Swift team is currently working on laying the groundwork
> for asynchronous APIs using an async/await model, which would presumably
> tie the throwing cases more naturally into the language than what is
> possible using completion-closures today, are we sure that this wouldn't
> duplicate any efforts there or be made obsolete through other means?
>
> In other words, while Result<> can be a very useful foundational component
> on its own, I think any proposal for it can't be made in isolation, but
> very much needs to consider other asynchronous work going on in the
> language.
>
>
> On Thu, Nov 2, 2017 at 11:15 AM Jon Shier via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> You don’t lose it, it’s just behind `Error`. You can cast out whatever
>> strong error type you need without having to bind an entire type to it
>> generically. If getting a common error type out happens a lot, I usually
>> add a convenience property to `Error` to do the cast for me. Plus, having
>> to expose an entire new error wrapper is just a non starter for me and
>> doesn’t seem necessary, given how Result is currently used in the community.
>>
>>
>> Jon
>>
>>
>> On Nov 2, 2017, at 2:12 PM, Dave DeLong <swift at davedelong.com> wrote:
>>
>> I think I’d personally rather see this done with a generic error as well,
>> like:
>>
>> enum GenericResult<T, E: Error> {
>> case success(T)
>> case failure(E)
>> }
>>
>> And a typealias:
>>
>> typealias Result<T> = GenericResult<T, AnyError>
>>
>> This would require an “AnyError” type to type-erase a specific Error, but
>> I’ve come across many situations where a strongly-typed error is *incredibly
>> *useful, and I’d be reluctant to see that thrown away.
>>
>> Dave
>>
>> On Nov 2, 2017, at 12: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
>>
>
>
>
> _______________________________________________
> 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/7f4db9ef/attachment.html>