<div dir="ltr">On Thu, Nov 2, 2017 at 7:04 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"><div style="word-wrap:break-word;line-break:after-white-space"><span class="gmail-m_-4718777734166823758Apple-tab-span" style="white-space:pre-wrap"> </span>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.</div></blockquote><div><br></div><div>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:</div><div><br></div><div>> How do we decide if something belongs in the standard library or Foundation?</div><div><br></div><div>> 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.</div><div><br></div><div>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.</div><div><br></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"><div style="word-wrap:break-word;line-break:after-white-space"><div><div class="gmail-h5"><div><div><blockquote type="cite"><div>On Nov 2, 2017, at 8:01 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="gmail-m_-4718777734166823758Apple-interchange-newline"><div><div dir="ltr">This is clearly a fine addition to the standard library; even Swift's Error Handling Rationale (<a href="https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst" target="_blank">https://github.com/apple/<wbr>swift/blob/master/docs/<wbr>ErrorHandlingRationale.rst</a>) mentions such an addition<br><br>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.<br><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><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"><div style="word-wrap:break-word;line-break:after-white-space">Swift-Evolution:<div><span class="gmail-m_-4718777734166823758m_-4434525584991225668Apple-tab-span" style="white-space:pre-wrap"> </span>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!) </div><div><br></div><div><a href="https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md" target="_blank">https://github.com/jshier/swif<wbr>t-evolution/blob/master/propos<wbr>als/0187-add-result-to-the-<wbr>standard-library.md</a></div><div><br></div><div><br></div><div>Thanks, </div><span class="gmail-m_-4718777734166823758HOEnZb"><font color="#888888"><div><br></div><div>Jon Shier</div><div><br></div><div><br></div></font></span></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>
</div></blockquote></div><br></div></div></div></div></blockquote></div><br></div></div>