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

[Jacob Williams]

Huge +1

Dealing with path manipulations via Foundation is a real pain on Linux. I
end up using a lot of C code from Glibc. And random support is another pain
point.

There are tons of uses for a non-std library, however, i would like to see
python style imports (if possible) to avoid importing a potentially large
library when i may only need one or two functions from it. I hate importing
all of foundation just so i csn work with Dates.

Same thing would be handy in a non-std library. I wont do much with
geometry or many other things, but i need a secure random number generator?
`import NonStd.SecureRandom`
Now I’ve got what I need for generating cryptographically secure random
numbers, but none of the additional bloat.

This is probably something that would require an additional proposal, and
I’m not even sure if it would be possible with the way swift compiles
frameworks, but it would be nice


On Wed, Nov 8, 2017 at 5:54 AM Karl Wagner via swift-evolution <
swift-evolution at swift.org> 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.
>
> - Karl
> _______________________________________________
> 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/20171108/2ea72740/attachment.html>