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

David Turnbull dturnbull at gmail.com
Thu Jan 28 22:54:52 CST 2016


I was thinking about the requirements to make this happen. It only needs
someone to do the initial organization. So I created a GitHub organization
and put up a couple projects. The Matrix4 project is feature-complete. The
Complex project is just a foothold.

Now we need more projects. The readme in the contrib project has
information about getting your project added.

https://github.com/swift-breeze

-david

On Tue, Jan 26, 2016 at 3:51 PM, Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

> +1.  I have already suggested that we have a space for libraries that get
> reviewed by the community but are distributed by SPM rather than being part
> of stdlib and corelibs.
>
>
> On Jan 26, 2016, at 5:48 PM, Howard Lovatt via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> This is a good idea. It will be a lot easier with the module system,
> particularly if that system is searchable so that you have a chance of
> finding that someone has already written what you want.
>
> On Wednesday, 27 January 2016, Trent Nadeau via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> This is similar to Rust's nursery (https://github.com/rust-lang-nursery)
>> that contains commonly used libraries (logging, UUIDs, etc). These are
>> under Rust's umbrella but aren't part of the standard library and can be
>> versioned separately but still go through a similar stdlib process. If
>> libraries in the nursery become very widely used, then an RFC can come in
>> requesting for it to be added to the stdlib, and most libraries need to be
>> in the nursery before they can be added to the stdlib.
>>
>> I think an approach like that would work well for Swift.
>>
>> On Tue, Jan 26, 2016 at 6: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
>>>
>>>
>>
>>
>> --
>> Trent Nadeau
>>
>
>
> --
>   -- Howard.
>
> _______________________________________________
> 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/20160128/645b6a82/attachment.html>


More information about the swift-evolution mailing list