[swift-evolution] Pitch: (Almost) std libs

[David Turnbull]

Rust has a Nursery. C++ gets a Boost. Swift is a Breeze? The only problem
is that a lot of stdlib-like things aren't suitable for modules.

For example, it would be unfortunate if a blogger was comparing languages
and benchmarked FFT using complex numbers from a module in the breeze.
Dynamic dispatch is going to devastate the benchmarks.

Still, it's worth pursuing this. There's a lot of things which Apple
supports on Apples and won't be a priority for stdlib. The quaternions you
mentioned are a good example. Complex numbers are another because of
Accelerate.

-david  https://github.com/AE9RB/SwiftGL


On Tue, Jan 26, 2016 at 3:32 PM, Tino Heth via swift-evolution <
swift-evolution at swift.org> wrote:

> There have been several threads to add specific functions or types to the
> stdlib:
> - Either in the Swift Standard Library
> - Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib
> - Higher Kinded Types (Monads, Functors, etc.)
> - Adding a new filter method which returns 2 arrays
> - Add replace(_:with:) function to the stdlib
> - map-like operation that returns a dictionary
> - Rectangles and other common structures.
> - Add zip2WithNilPadding function
> - Add types BufferedSequence, BufferedGenerator
> - … (guess there are some that I missed — I didn't look at last years
> threads at all).
>
> Afair, none of those ideas turned into real proposals, and I think that
> keeping stdlib small is a good goal.
>
> Nonetheless, there are plenty of data structures and algorithms that will
> be used in many places by many different teams, and each of them might
> write its own implementation. That's imho no big problem for algorithms,
> but for types, it will most likely lead to real annoyance.
>
> I hope that we will soon have a great package manager for Swift, but I
> don't think that will solve this issue completely:
> I wouldn't import a big third-party framework just because a tiny function
> like "dropWhile" could make my code more elegant...
>
> Of course, some widely accepted libs might rise and improve
> interoperability, but it is hard to predict how our ecosystem will evolve,
> and you don't have to wait for the future to see the what could happen when
> there is no common base:
> Just take a look at SCNQuaternion, GLQuaternion and CMQuaternion.
>
> Instead of asking to pollute stdlib with stuff like 3d transformations,
> I'd prefer a set of general purpose libraries under supervision by the
> Swift team:
> It could be a great way for "outsiders" to get into Swift development, and
> most likely wouldn't put to much stress and responsibility on the shoulders
> of each "manager".
> It also could take pressure from the stdlib (and this mailinglist :)
>
> Beside fields of application (graphics, images, music, algebra,
> statistics, pattern matching, machine learning, graph theorie... whatever
> raises enough interest), there could also be libraries to support concepts
> like functional programming.
>
> Best regards,
> Tino
>
>
> _______________________________________________
> 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/20160126/a2303c89/attachment.html>