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

[Trent Nadeau]

I'm confused. Why would you get dynamic dispatch for a complex number just
because it's in another module? I think a complex number would always be a
struct so everything would be inline to the storage on the stack, and
there's no inheritance so no vtable.

On Tue, Jan 26, 2016 at 7:46 PM, David Turnbull via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Trent Nadeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160126/a04bffb9/attachment.html>