<div dir="ltr">On Thu, Nov 2, 2017 at 9:36 PM, Jon Shier <span dir="ltr"><<a href="mailto:jon@jonshier.com" target="_blank">jon@jonshier.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">> 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.<br>
<br>
</span> 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.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
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?<br></blockquote><div><br></div><div>Built-in support could include such things as:</div><div>* language support for "unwrapping," analogous (though of course not identical) to `?` and `!`</div><div>* 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</div><div>* 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<br></div><div><br></div><div>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.</div><div><br></div><div>The Swift Error Handling Rationale document itself mentions similar as well as additional Result-related needs:</div><div><br></div><div><div>> A function to evaluate an error-producing closure and capture the result as a Result<T>.<br></div><div>> A function to unpack a Result<T> by either returning its value or propagating the error in the current context.</div><div>> A futures library that traffics in Result<T> when applicable.</div><div>> An overload of dispatch_sync which takes an error-producing closure and propagates an error in the current context.</div><div>> etc.</div></div><div><br></div><div>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?</div><div><br></div></div></div></div>