<div dir="ltr">i’m not one to applaud everything go does but its extended standard library seems nice<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 9, 2017 at 2:24 AM, Nick Keets 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:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div>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:</div><div><br></div><div><a href="https://golang.org/pkg/" target="_blank">https://golang.org/pkg/</a></div><div><br></div><div>To summarize, it includes:</div><div>- archival and compression formats (tar, zip, gzip, ...)</div></div></blockquote><div><br></div><div>will be an open problem to port zlib to Swift, but it’s doable<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- a few data structures</div></div></blockquote><div><br></div><div>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 <span style="font-family:monospace,monospace">std::priority_queue</span>. at this point i just have <span style="font-family:monospace,monospace">Queue.swift</span> file lying around that I copy and paste whenever i need it. which is bad.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- cryptographic functions (including hashes and random numbers)</div></div></blockquote><div><br></div><div>This is being talked about right now, mostly about random number generation, less on cryptography since it’s really easy to mess that up<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- sqlite and basic database drivers support</div><div>- various data encodings (CSV, XML, JSON, ...)</div></div></blockquote><div><br></div><div>I have an <a href="https://github.com/kelvin13/swiftxml">Linux-compatible XML library</a> in progress, last I remember the Foundation class didn’t work on Linux<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- some stuff used internally by the go tools (AST trees, debugging symbols)</div><div>- basic graphics and image support</div></div></blockquote><div><br></div><div>i maintain a Swift <a href="https://github.com/kelvin13/maxpng">PNG codec</a>, and am developing a pure Swift <a href="https://github.com/kelvin13/jpeg">JPEG codec</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- basic text and HTML templates</div></div></blockquote><div><br></div><div>could really use these, don’t know of any cross-platform Swift libraries for these<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- math and bignums</div></div></blockquote><div><br></div><div>peep <a href="https://github.com/attaswift/BigInt">https://github.com/attaswift/BigInt</a> and <a href="https://github.com/xwu/NumericAnnex">https://github.com/xwu/NumericAnnex</a> <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- networking and HTTP support (client and server) <br></div></div></blockquote><div><br></div><div>isn’t there a server working group?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>- OS support (including path handling, command line flags etc)</div></div></blockquote><div><br></div><div>YES. currently working on a <a href="https://github.com/kelvin13/url">new URI type</a> to replace the Foundation one which is really just a wrapper around NSURL which is in turn a wrapper around CFURL. which is bad.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- Miscellanous stuff like dates, unicode, IO, string parsing, testing, etc.</div></div></blockquote><div><br></div><div>yes <br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-h5">On Wed, Nov 8, 2017 at 9:37 PM, Ted Kremenek via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><div style="overflow-wrap: break-word;"><span><div dir="auto"><div></div><div><br></div><div><br>On Nov 8, 2017, at 4:54 AM, Karl Wagner <<a href="mailto:razielim@gmail.com" target="_blank">razielim@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div><div dir="auto"><div><div><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><div>On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><div><div style="overflow-wrap: break-word;"><div><br></div><div>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.</div></div></div></blockquote><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">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.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">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.</div></div></div></div></div></div></div></blockquote><blockquote type="cite"><div dir="auto"><div><div><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">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.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div></div></div></div></div></blockquote><br></div></span><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div></div><br></div></div><span class="gmail-">______________________________<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></span></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div></div>