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

[Howard Lovatt]

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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
> Trent Nadeau
>


-- 
  -- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160127/93e915dc/attachment.html>