On Thu, Nov 2, 2017 at 7:04 PM, Jon Shier <[email protected]> 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 <[email protected]> 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 < > [email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
