i’m not one to applaud everything go does but its extended standard library seems nice
On Thu, Nov 9, 2017 at 2:24 AM, Nick Keets via swift-evolution < swift-evolution@swift.org> wrote: > I think there are two ideas discussed in this thread at the same time. One > is for a more extended standard library, that is developed and shipped as > part of the language. This is similar to what Python, Go and other > languages are doing. The second is for a more wide collection of packages, > developed by 3rd parties and not included with the language. This is > similar to npm, PyPI, etc. > > If I understood it correctly, the original proposal is about the first > idea and I don't think an "open market" approach works well for this. As > for what should be included, I find Go to be a nice example, that could be > used as a starting point: > > https://golang.org/pkg/ > > To summarize, it includes: > - archival and compression formats (tar, zip, gzip, ...) > will be an open problem to port zlib to Swift, but it’s doable > - a few data structures > lots of incomplete implementations floating around GitHub, none really stand out because i feel like most people have gotten used to rolling their own since we still don’t have a Swift equivalent of std::priority_queue. at this point i just have Queue.swift file lying around that I copy and paste whenever i need it. which is bad. > - cryptographic functions (including hashes and random numbers) > This is being talked about right now, mostly about random number generation, less on cryptography since it’s really easy to mess that up > - sqlite and basic database drivers support > - various data encodings (CSV, XML, JSON, ...) > I have an Linux-compatible XML library <https://github.com/kelvin13/swiftxml> in progress, last I remember the Foundation class didn’t work on Linux > - some stuff used internally by the go tools (AST trees, debugging symbols) > - basic graphics and image support > i maintain a Swift PNG codec <https://github.com/kelvin13/maxpng>, and am developing a pure Swift JPEG codec <https://github.com/kelvin13/jpeg> > - basic text and HTML templates > could really use these, don’t know of any cross-platform Swift libraries for these > - math and bignums > peep https://github.com/attaswift/BigInt and https://github.com/xwu/NumericAnnex > - networking and HTTP support (client and server) > isn’t there a server working group? > - OS support (including path handling, command line flags etc) > YES. currently working on a new URI type <https://github.com/kelvin13/url> to replace the Foundation one which is really just a wrapper around NSURL which is in turn a wrapper around CFURL. which is bad. > - Miscellanous stuff like dates, unicode, IO, string parsing, testing, etc. > yes > Go considers all these packages part of the language and offers source > compatibility guarantees for all of them. I find the availability of these > packages and the fact that they are developed and maintained by the Go core > team to be very powerful. > > We can debate what should be included and if these should be separate > modules or not, but I think the key insight here is that they are a curated > list of useful libraries that are developed and maintained together with > the language. > > > On Wed, Nov 8, 2017 at 9:37 PM, Ted Kremenek via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >> On Nov 8, 2017, at 4:54 AM, Karl Wagner <razie...@gmail.com> wrote: >> >> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> FWIW, Ben Cohen and I have been talking about possibly using Swift >> packages as a way to seed out experimental ideas for extensions to the >> Standard Library. This would allow ideas to be trialed by real usage (a >> complaint I’ve seen about some changes we’ve made to Swift in the past). >> Users could build things on top of those libraries, knowing they are >> available as packages, and if an API “graduates” to being part of the >> Standard Library the user can then depend upon it being available there. >> If it never graduates, however, the package remains around. >> >> >> Yeah this is exactly the problem that the package manager is there to >> solve, right? It’s supposed to make it ridiculously easy to integrate >> libraries and manage your dependencies. >> >> The problem is that most people writing Swift code every day are doing it >> to make graphical applications on iOS/macOS. SwiftPM doesn’t support those, >> so if I want to test a library, it’s just a one-off thing that I play with >> in a Playground. >> >> >> I think that the best thing we could do to encourage people to write, use >> and contribute to public libraries would be to improve the package manager. >> SwiftPM is still basically a toy (or an interesting curiosity), until it >> can actually be used in the projects most Swift devs get paid to work on >> every day. Talking about it supporting a community is way premature; it’s >> not even close to ready to taking on that responsibility, IMO. >> >> >> I agree that the tooling support around SwiftPM is not sufficiently >> advanced yet to support this for everybody. Further, I don’t think there >> would be a need to preclude other ways to share libraries for this purpose, >> even if the SwiftPM tooling support was more mature. >> >> The primary point I wanted to make was more about the model itself. I’d >> prefer the community grow up a set of libraries that trialed and used >> before focusing on prematurely baking them into the core Swift distribution. >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution