[swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma]

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 at 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 at swift.org> wrote:
>
>>
>>
>> On Nov 8, 2017, at 4:54 AM, Karl Wagner <razielim at gmail.com> wrote:
>>
>> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution <
>> swift-evolution at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171109/9d109ea0/attachment.html>