[swift-evolution] Adding Result to the Standard Library

[Xiaodi Wu]

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

> > 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.
>
>         What? That doesn’t make any sense at all. I’ve written this
> proposal to get a very popular and useful type into the standard library
> exactly because it’s so popular and useful. It’s so popular and useful, in
> fact, that users are running into issues getting all of the third-party
> implementations to play well together. I’ll be adding more to the proposal
> about the general usefulness of the Result type tomorrow, but it has often
> been said on this mailing list that one of the ways a type can become part
> of the standard library is by becoming popular in the community.


No no no, that's often been said to be one of the ways to have something
accepted as a _new core library_ (like Foundation, Dispatch, etc.), not as
a part of the standard library. The Swift server API working group, for
example, is working on bootstrapping one or multiple such additional core
libraries.

The standard library is deliberately small, includes facilities essential
for the language itself requiring built-in support, and does *not* have a
goal of supplying all generally useful or sought-after functionality. This
is why, as the Swift Foundation project states, URL is appropriately part
of Foundation and *not* the standard library.


> My assertion is that Result has reached that point and so needs
> consideration for the benefit of not only all current users of the type,
> but the community in general.
>

I do think you have a good argument to make that error handling is
fundamentally a "language" and not a "library" feature. But you would need
to make the case convincingly by demonstrating how it benefits from
language features. Otherwise, it's a candidate for being part of some core
library but *not* a great candidate for the standard library.


>         I could also be confused about what you mean about “built-in”
> support, or the types of things you’d think a standard library Result type
> should do that isn’t in the proposal. In that case, could you be much more
> specific about what additions you think it needs?
>

Built-in support could include such things as:
* language support for "unwrapping," analogous (though of course not
identical) to `?` and `!`
* compiler magic to reconcile `() throws -> Int` and `() -> Result<Int>` so
that one spelling can be used as an implementation for a protocol
requirement spelled differently, or one spelling can be used in a subclass
overriding a method spelled differently
* any other conveniences necessary to make interconversion between `() ->
Result<T>`, `() throws -> T`, `() -> T?`, and `() -> T!` more fluid from
the caller side or from the library writer side

I am not saying that `Result` definitely needs these things, although I
suspect it could benefit from at least a few such well-designed language
features. In my view, a complete proposal for the _standard library_ would
look into these conveniences, evaluate different possible designs for each,
then discuss which most improve user ergonomics and cohesion of the
language.

The Swift Error Handling Rationale document itself mentions similar as well
as additional Result-related needs:

> A function to evaluate an error-producing closure and capture the result
as a Result<T>.
> A function to unpack a Result<T> by either returning its value or
propagating the error in the current context.
> A futures library that traffics in Result<T> when applicable.
> An overload of dispatch_sync which takes an error-producing closure and
propagates an error in the current context.
> etc.

In proposing the addition of `Result`, some overarching vision needs to be
articulated that firstly answers the question of: what is or should be part
of the "etc." mentioned above, and how must we design `Result` and any
accompanying language features so that we can eventually get there?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171102/eb64918e/attachment.html>