So, this has been discussed before on the list many times in the past. The
core team has stated that their preferred process for this is to have
individuals write their own libraries, get real-world adoption, then (as
consensus emerges) propose their inclusion as a core library.
While I respect the free-market idealism, I think there’s a reason no one
has ever seriously proposed their library to be included as a core library.
To be completely honest, I think core libraries are a lot like highways.
They’ll never get built if you wait for people to do it themselves. A lot
of people (including myself) release their own toolkit on Github; it tends
to be just good enough and comprehensive enough to serve their own needs.
Each one has maybe 1% adoption and none of them really stand out or are
seen as the “best” choice so people just write their own
<https://xkcd.com/927/> in-house solution. There’s no Swift package index
(like docs.rs) so even if someone tries to start a core library project (or
any library project at all!), no one will ever know about it. There’s also
no positive feedback loop whereby if a core library project gets off the
ground <https://github.com/PureSwift>, it’ll actually make it to maturity.
I’m not gonna get into subjective opinions about having strong open source
traditions or lack thereof.
Add the fact that we don’t have cross module optimizations yet, and it’s no
wonder why the community has never produced a “consensus” core library.
I’m not saying the Swift team should devote any time or resources to
writing these things, but it’d be a huge benefit if someone were to say
“okay we are commissioning a core library that does X, the code will live
in Y Github repository, we’ve set up Z mailing list for this, and anyone
who is willing to invest time in this is welcome to help make this a
reality”. Then everyone with an interest in seeing these things get built
would be able to coordinate.
Keep in mind that the _standard_ library is what's available by default
without importing anything; it is deliberately small and includes only the
most basic types that need compiler support. This is different to be
distinguished from core libraries like Foundation and Dispatch.
I think we’re getting tripped up on two different uses of the word
“standard”. Python’s math
<math — Mathematical functions — Python 3.12.0 documentation; module isn’t part
of its stdlib, but it basically “comes with” the interpreter.
With that exhortation in mind, I have written a math library that provides
protocol-based trigonometry. For expediency it wraps Darwin or Glibc at the
moment. It is intended to be an exercise in creating a plausible design
that respects existing Swift conventions. On top of that, it includes
implementations for complex and rational numbers, as well as pseudorandom
number generators (unfinished at the moment); I include the link here as a
reply regarding what I feel would be the optimal design (in terms of free
function vs. members) for such a math protocol:
GitHub - xwu/NumericAnnex: Numeric facilities for Swift
That’s a great project, thank you for sharing! If we ever got an “official”
math module started, I think it would make a great seed.
···
On Mon, Jul 31, 2017 at 9:11 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Mon, Jul 31, 2017 at 7:37 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote:
I’d be completely in favor of this. Structs for priority queues,
skiplists, trees, binary search and more sorting functions would also be on
my wishlist. I think Python made a very good choice in choosing to vend
separate standard modules for stuff like that instead of bloating its
builtin namespace.
On Mon, Jul 31, 2017 at 2:22 PM, Hooman Mehr <hooman@mac.com> wrote:
Maybe we need more than one level of standard library: The core (which
is most of what we have now (but maybe not all of it) and multiple opt-in
standard modules for hash functions, math, specialized data structures, etc.
On Jul 31, 2017, at 11:10 AM, Taylor Swift <kelvin13ma@gmail.com> wrote:
I’m not sure why only the stdlib is inlineable and specializable, but I
believe it has something to do with ABI. I’m not an ABI expert though. I
strongly disagree that a Swift Math library should be delegated to a third
party. Math is “common” enough that there should really only be one
“standard” implementation of it, under the direction of the Swift Project;
we don’t want 5 competing third party Vector standards.
On Mon, Jul 31, 2017 at 2:02 PM, Hooman Mehr <hooman@mac.com> wrote:
I know. I hear you. I have some special arrangmnents to keep such
things manageable, and I am not happy about how things stand right now.
What I am hoping to open up stdlib special compiler mode to other
(low-level) libraries and also letting such libraries gain optimizations
similar to stdlib when included in a project.
So, instead of putting things in stdlib, I want stdlib’s special
privileges being made available to a certain category of third-party or
internal modules.
On Jul 31, 2017, at 10:54 AM, Taylor Swift <kelvin13ma@gmail.com> >>>> wrote:
Isn’t the point of standard inlineable library module to prevent the
need to copy and paste code like this into every project? Currently I have
a “math.swift” file I copy and paste into all of my projects, and since I
occasionally update it, there exists about 15 different versions of it
floating around, so I know this is not a sustainable practice.
On Mon, Jul 31, 2017 at 1:45 PM, Hooman Mehr <hooman@mac.com> wrote:
I prefer an approach that preserves how I am used to seeing math
expressions. I use this myself:
protocol FloatingPointMath: FloatingPoint
{
static func sqrt(_ value: Self) -> Self
static func sin(_ value: Self) -> Self
static func cos(_ value: Self) -> Self
static func tan(_ value: Self) -> Self
static func asin(_ value: Self) -> Self
static func acos(_ value: Self) -> Self
static func atan(_ value: Self) -> Self
static func ln(_ value: Self) -> Self
static func log(_ value: Self, base: Self) -> Self
static func pow(_ value: Self, exponent:Self) -> Self
static func exp(_ value: Self) -> Self
}
It does not pollute the global namespace and gives nice contextual
auto-completion. And I don’t want it in the standard library: I only add
the file when I need it. (it is not a separate module for optimization
reasons).
On Jul 31, 2017, at 10:29 AM, Taylor Swift via swift-evolution < >>>>> swift-evolution@swift.org> wrote:
On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev < >>>>> adrian.zubarev@devandartist.com> wrote:
I’m not sure how I would feel about this. To be honest I’d avoid such
additional changes from the stdlib, because they really don’t belong there.
Instead some `Math` module/package would be a better fit than clustering
everything into stdlib until we end up also adding UI stuff.
Furthermore, I don’t think a function would make any sense here. It
really should be a computed property.
I think a standard Math module would be a good idea, but only if it
benefits from the same inlining and specialization as the standard library.
Also squareRoot() should be moved to the Math module if it is ever created.
Am 31. Juli 2017 um 19:03:49, Taylor Swift via swift-evolution (
swift-evolution@swift.org) schrieb:
How would people feel about adding a protocol
protocol MathFloatingPoint:FloatingPoint
{
func sin() -> Self
func cos() -> Self
func tan() -> Self
func asin() -> Self
func acos() -> Self
func atan() -> Self
func ln() -> Self
func log(base:Self) -> Self
func pow(exponent:Self) -> Self
func exp() -> Self
}
to the standard library? Float and Double would then be made to
conform by default using Swift implementations instead of having to import
Glibc / Darwin and writing the extensions, depending on platform.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution