[swift-evolution] Adding Result to the Standard Library

[Xiaodi Wu]

On Thu, Nov 2, 2017 at 7:04 PM, Jon Shier <jon at jonshier.com> wrote:

> I’m certainly willing to adjust API to better match convention and
> guidelines. However, part of the proposal’s basis is the popularity of the
> Alamofire implementation (which is rather similar to the antitypical one in
> regards to additional API offered). Adding special syntax for it isn’t
> really something I want to do, as ever bit of that needs additional
> justification beyond the fact that’s it’s already in use.
>

On the contrary, every addition to the standard library must justify why it
must be in *the standard library*, as opposed to another core library or a
third-party library. Consider this standard articulated in the Foundation
README:

> How do we decide if something belongs in the standard library or
Foundation?

> In general, the dividing line should be drawn in overlapping area of what
people consider the language and what people consider to be a library
feature. For example, Optional is a type provided by the standard library.
However, the compiler understands the concept to provide support for things
like optional-chaining syntax. The compiler also has syntax for creating
Arrays and Dictionaries. On the other hand, the compiler has no built-in
support for types like URL. URL also ties into more complex functionality
like basic networking support. Therefore this type is more appropriate for
Foundation.

I would argue that a successful addition to the standard library *must*
have such additional justification about why it needs built-in support. If
it's already in use as a third-party library, and you're arguing that the
third-party design is already quite satisfactory and there's no built-in
support required, then that's fundamentally an argument that it *doesn't*
need to be in the standard library.

On Nov 2, 2017, at 8:01 PM, Xiaodi Wu <xiaodi.wu at gmail.com> 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/propos
>> als/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/366b7796/attachment.html>