TrigonometricFloatingPoint/MathFloatingPoint protocol?

Evolution Discussion
21

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.

I already opened a new mail to write my answer, but than I thought "wait,
scroll down, and look if Xiaodi did already post links" ;-)
[But where have those potential core libraries been mentioned?]

Anyways, my perception hasn't change much:
I think it would be enough if someone from Apple would say "here's an
empty github-repo called
[math/statistics/algebra/crypto/graphic/image/audio/music/video/smtp/http…];
feel free to fork and create pull requests" and adding some democratic
mechanism for acceptance on top of it.

What would be your compatibility and stability expectations of such APIs?
If there are any expectations, then the APIs would need careful design and
thought. The Swift project faces a lot of design bandwidth limitations, so
prioritize is always tricky.

The point of spinning off separate core library working groups would be so
that library feature requests and proposals can stop clogging up
swift-evolution. Then the swift-evolution core team could focus on the
compiler and the standard library and the community would take stewardship
of the core libraries through separate channels.

My understanding is that the server working group, and all such work
groups, will be presenting their proposals here for approval, and that all
API changes in the Swift open source project go through this list.

But as long as no one with enough reputation starts Swifts equivalent of

···

On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution < swift-evolution@swift.org> wrote:

On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution < > swift-evolution@swift.org> wrote:

On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution < >> swift-evolution@swift.org> wrote:
boost, there won't be a set of established libraries for basic data
structures and algorithms outside the stdlib.

For anyone who thinks there's no need for a standard lib that is not the
stdlib, have a look at
GLKQuaternion | Apple Developer Documentation
SCNQuaternion | Apple Developer Documentation
CMQuaternion | Apple Developer Documentation
:-(

Tino
_______________________________________________
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

22

I think the Server APIs project was pretty close to what I had in mind
actually. I don’t see why more core libraries can’t be commissioned that
way, things like Math and DateTime would probably draw a great deal more
attention than Server APIs since they are used by more people. One thing
that would have to be fixed though is the cross-module optimization
problem; no one in their right mind should ever be making generic calls to
sin(x). A feature in the SPM that would perform “injection” of core library
code into the interior of modules would probably be enough to fix this
problem for now. (If this sounds hacky just remember that right now
everyone seems to be copying and pasting .swift files everywhere.)
Everything internal would become fileprivate and everything public would
become internal. A good Swift library should expose no more than 7 or 8
symbols at the top level so this should play nice with most client projects.

···

On Tue, Aug 1, 2017 at 4:50 AM, Ian Partridge <ian@poncho.org.uk> wrote:

On 1 August 2017 at 04:46, Taylor Swift via swift-evolution > <swift-evolution@swift.org> wrote:
> 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.

That's what's happened with the Server APIs Project
https://swift.org/server-apis/

I would like to see more of this, and math/BigNum seems like a good
candidate.

Another is a modern date/time package, standing on the shoulders of
The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 310 and similar.

--
Ian Partridge

23

That's what's happened with the Server APIs Project
https://swift.org/server-apis/

I would like to see more of this, and math/BigNum seems like a good candidate.

Another is a modern date/time package, standing on the shoulders of
The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 310 and similar.

+ 1

I would also love to see standard implementation of Graph data structures, at least some common protocols.
Dunno why this versatile data structure is not included in standard libraries (similar to Map/Dictionary), Set, etc.

-g.

1 Like
24

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.

I already opened a new mail to write my answer, but than I thought
"wait, scroll down, and look if Xiaodi did already post links" ;-)
[But where have those potential core libraries been mentioned?]

Anyways, my perception hasn't change much:
I think it would be enough if someone from Apple would say "here's an
empty github-repo called [math/statistics/algebra/crypt
o/graphic/image/audio/music/video/smtp/http…]; feel free to fork and
create pull requests" and adding some democratic mechanism for acceptance
on top of it.

What would be your compatibility and stability expectations of such
APIs? If there are any expectations, then the APIs would need careful
design and thought. The Swift project faces a lot of design bandwidth
limitations, so prioritize is always tricky.

The point of spinning off separate core library working groups would be
so that library feature requests and proposals can stop clogging up
swift-evolution. Then the swift-evolution core team could focus on the
compiler and the standard library and the community would take stewardship
of the core libraries through separate channels.

My understanding is that the server working group, and all such work
groups, will be presenting their proposals here for approval, and that all
API changes in the Swift open source project go through this list.

That sounds like it would spam the general list a lot?

On the contrary, core team members have confirmed that working proposals
such as those are the principal intended use for this list; it is *not*
meant to be a general forum for musings about Swift language design.

···

On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift <kelvin13ma@gmail.com> wrote:

On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution < >> swift-evolution@swift.org> wrote:

On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution < >>> swift-evolution@swift.org> wrote:

On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution < >>>> swift-evolution@swift.org> wrote:

Wouldn’t a more decentralized model mitigate the “we don’t have the
energy/attention to devote to this” complaint?

Also as a gauge of interest, I’m wondering who here would like to work on
a core library if a campaign to build some was started now.

But as long as no one with enough reputation starts Swifts equivalent of

boost, there won't be a set of established libraries for basic data
structures and algorithms outside the stdlib.

For anyone who thinks there's no need for a standard lib that is not
the stdlib, have a look at
GLKQuaternion | Apple Developer Documentation
SCNQuaternion | Apple Developer Documentation
CMQuaternion | Apple Developer Documentation
:-(

Tino
_______________________________________________
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

25

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.

I already opened a new mail to write my answer, but than I thought
"wait, scroll down, and look if Xiaodi did already post links" ;-)
[But where have those potential core libraries been mentioned?]

Anyways, my perception hasn't change much:
I think it would be enough if someone from Apple would say "here's an
empty github-repo called [math/statistics/algebra/
crypto/graphic/image/audio/music/video/smtp/http…]; feel free to fork
and create pull requests" and adding some democratic mechanism for
acceptance on top of it.

What would be your compatibility and stability expectations of such
APIs? If there are any expectations, then the APIs would need careful
design and thought. The Swift project faces a lot of design bandwidth
limitations, so prioritize is always tricky.

The point of spinning off separate core library working groups would be
so that library feature requests and proposals can stop clogging up
swift-evolution. Then the swift-evolution core team could focus on the
compiler and the standard library and the community would take stewardship
of the core libraries through separate channels.

My understanding is that the server working group, and all such work
groups, will be presenting their proposals here for approval, and that all
API changes in the Swift open source project go through this list.

That sounds like it would spam the general list a lot? Wouldn’t a more
decentralized model mitigate the “we don’t have the energy/attention to
devote to this” complaint?

Also as a gauge of interest, I’m wondering who here would like to work on a
core library if a campaign to build some was started now.

···

On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote:

On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution < >> swift-evolution@swift.org> wrote:

On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution < >>> swift-evolution@swift.org> wrote:

But as long as no one with enough reputation starts Swifts equivalent of

boost, there won't be a set of established libraries for basic data
structures and algorithms outside the stdlib.

For anyone who thinks there's no need for a standard lib that is not the
stdlib, have a look at
GLKQuaternion | Apple Developer Documentation
SCNQuaternion | Apple Developer Documentation
CMQuaternion | Apple Developer Documentation
:-(

Tino
_______________________________________________
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

26

A thousand times yes to this.

···

On Tue, Aug 1, 2017 at 9:35 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote:

On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift <kelvin13ma@gmail.com> wrote:

On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution < >>> swift-evolution@swift.org> wrote:

On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution < >>>> swift-evolution@swift.org> wrote:

On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution < >>>>> swift-evolution@swift.org> wrote:

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.

I already opened a new mail to write my answer, but than I thought
"wait, scroll down, and look if Xiaodi did already post links" ;-)
[But where have those potential core libraries been mentioned?]

Anyways, my perception hasn't change much:
I think it would be enough if someone from Apple would say "here's an
empty github-repo called [math/statistics/algebra/crypt
o/graphic/image/audio/music/video/smtp/http…]; feel free to fork and
create pull requests" and adding some democratic mechanism for acceptance
on top of it.

What would be your compatibility and stability expectations of such
APIs? If there are any expectations, then the APIs would need careful
design and thought. The Swift project faces a lot of design bandwidth
limitations, so prioritize is always tricky.

The point of spinning off separate core library working groups would be
so that library feature requests and proposals can stop clogging up
swift-evolution. Then the swift-evolution core team could focus on the
compiler and the standard library and the community would take stewardship
of the core libraries through separate channels.

My understanding is that the server working group, and all such work
groups, will be presenting their proposals here for approval, and that all
API changes in the Swift open source project go through this list.

That sounds like it would spam the general list a lot?

On the contrary, core team members have confirmed that working proposals
such as those are the principal intended use for this list; it is *not*
meant to be a general forum for musings about Swift language design.

Wouldn’t a more decentralized model mitigate the “we don’t have the
energy/attention to devote to this” complaint?

Also as a gauge of interest, I’m wondering who here would like to work on
a core library if a campaign to build some was started now.

But as long as no one with enough reputation starts Swifts equivalent of

boost, there won't be a set of established libraries for basic data
structures and algorithms outside the stdlib.

For anyone who thinks there's no need for a standard lib that is not
the stdlib, have a look at
GLKQuaternion | Apple Developer Documentation
SCNQuaternion | Apple Developer Documentation
CMQuaternion | Apple Developer Documentation
:-(

Tino
_______________________________________________
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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

27

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.

I already opened a new mail to write my answer, but than I thought "wait, scroll down, and look if Xiaodi did already post links" ;-)
[But where have those potential core libraries been mentioned?]

Anyways, my perception hasn't change much:
I think it would be enough if someone from Apple would say "here's an empty github-repo called [math/statistics/algebra/crypto/graphic/image/audio/music/video/smtp/http…]; feel free to fork and create pull requests" and adding some democratic mechanism for acceptance on top of it.

What would be your compatibility and stability expectations of such APIs? If there are any expectations, then the APIs would need careful design and thought. The Swift project faces a lot of design bandwidth limitations, so prioritize is always tricky.

The point of spinning off separate core library working groups would be so that library feature requests and proposals can stop clogging up swift-evolution. Then the swift-evolution core team could focus on the compiler and the standard library and the community would take stewardship of the core libraries through separate channels.

My understanding is that the server working group, and all such work groups, will be presenting their proposals here for approval, and that all API changes in the Swift open source project go through this list.

That sounds like it would spam the general list a lot?

On the contrary, core team members have confirmed that working proposals such as those are the principal intended use for this list; it is *not* meant to be a general forum for musings about Swift language design.

My rule of thumb was that any post on the mailing list that I make has to be aimed at providing a solution to a problem, or at the very least, seeking help in providing a solution to a problem. If the discussion has no definitive actionable outcome, then I consider it pointless.

···

On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift <kelvin13ma@gmail.com <mailto:kelvin13ma@gmail.com>> wrote:
On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:
On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Wouldn’t a more decentralized model mitigate the “we don’t have the energy/attention to devote to this” complaint?

Also as a gauge of interest, I’m wondering who here would like to work on a core library if a campaign to build some was started now.

But as long as no one with enough reputation starts Swifts equivalent of boost, there won't be a set of established libraries for basic data structures and algorithms outside the stdlib.

For anyone who thinks there's no need for a standard lib that is not the stdlib, have a look at
GLKQuaternion | Apple Developer Documentation
SCNQuaternion | Apple Developer Documentation
CMQuaternion | Apple Developer Documentation
:-(

Tino
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

28

I think the Server APIs project was pretty close to what I had in mind actually. I don’t see why more core libraries can’t be commissioned that way, things like Math and DateTime would probably draw a great deal more attention than Server APIs since they are used by more people. One thing that would have to be fixed though is the cross-module optimization problem; no one in their right mind should ever be making generic calls to sin(x). A feature in the SPM that would perform “injection” of core library code into the interior of modules would probably be enough to fix this problem for now. (If this sounds hacky just remember that right now everyone seems to be copying and pasting .swift files everywhere.) Everything internal would become fileprivate and everything public would become internal. A good Swift library should expose no more than 7 or 8 symbols at the top level so this should play nice with most client projects.

This is already planned as part of how Modules will be able to control what is and is not part of their ABI: https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#inlineable-functions

···

On Aug 1, 2017, at 8:02 AM, Taylor Swift via swift-evolution <swift-evolution@swift.org> wrote:

On Tue, Aug 1, 2017 at 4:50 AM, Ian Partridge <ian@poncho.org.uk <mailto:ian@poncho.org.uk>> wrote:
On 1 August 2017 at 04:46, Taylor Swift via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 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.

That's what's happened with the Server APIs Project
https://swift.org/server-apis/

I would like to see more of this, and math/BigNum seems like a good candidate.

Another is a modern date/time package, standing on the shoulders of
The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 310 <The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 310; and similar.

--
Ian Partridge

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

29

I’ve noticed from this and older threads that everyone agrees on what core libraries we want, but they never actually get built. Perennial requests seem to be

- RNG and cryptography library (CryptoSwift could be a good base for this)

A new implementation of crypto is probably a very bad idea. A blessed wrapping around the platform’s preferred implementation of crypto, however, is certainly needed.

- Generic Math library/Vector library

This is pretty compelling.

- Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList, graphs, etc)

Which flavor/implementation of tree, balanced tree, heap, graphs are desirable here? The desirability of many of these structures is often dependent on which of many competing tradeoffs were made. Implementation details can dramatically shape the general applicability of a data structure.

For example, it might make sense to adopt something similar to GitHub - attaswift/BTree: Fast sorted collections for Swift using in-memory B-trees as a general underlying representation for some kinds of higher level collections (or the mechanisms to easily adapt them).

- Modern DateTime library

Foundation provides many of these, though I’m sure there are always opportunities for improvement. Do you see a specific need that cannot be addressed with improvements to corelibs-foundation? There’s a large amount of domain expertise in Foundation and they are pretty active on the mailing lists.

- Modern String processing toolkit

This is a huge gap in Swift’s current offerings, and I’m personally invested in improving the situation here. At the risk of hijacking this thread, do you have a good bullet list of the kinds of facilities you imagine useful? More specifically (and to keep the discussion scoped), are there any tools beyond something like good language support for regular expression matching and substitutions?

- 2D Graphics library (similar to cairo)
- Windowing/UI library

By this, do you mean cross-platform pure Swift rethinks? This is certainly interesting, but a pure Swift rethink is likely a lower priority than exposing bindings for existing cross-platform approaches (e.g. you mentinoed cairo). Like crypto, it might make sense to establish blessed wrappers/apinotes/overlays on top of tried-and-true open source offerings.

···

On Aug 1, 2017, at 8:14 AM, Taylor Swift via swift-evolution <swift-evolution@swift.org> wrote:

I think David Turnbull tried to get something like this started years back but it fizzled out pretty quick, probably because the Swift foss community was much smaller back then. Time to try again?

On Tue, Aug 1, 2017 at 8:29 AM, Georgios Moschovitis <george.moschovitis@icloud.com <mailto:george.moschovitis@icloud.com>> wrote:
> That's what's happened with the Server APIs Project
> https://swift.org/server-apis/
>
> I would like to see more of this, and math/BigNum seems like a good candidate.
>
> Another is a modern date/time package, standing on the shoulders of
> The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 310 <The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 310; and similar.

+ 1

I would also love to see standard implementation of Graph data structures, at least some common protocols.
Dunno why this versatile data structure is not included in standard libraries (similar to Map/Dictionary), Set, etc.

-g.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

30

I’ve noticed from this and older threads that everyone agrees on what core libraries we want, but they never actually get built. Perennial requests seem to be

- RNG and cryptography library (CryptoSwift could be a good base for this)
- Generic Math library/Vector library
- Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList, graphs, etc)
- Modern DateTime library

This may not be a popular opinion for the masses, but in reality, Foundation is a modern DateTime library. The core functionality provided by Calendar, Date, TimeZone, Locale, and DateFormatter are world-class APIs.

I suspect that what people are really asking for is simpler API to do things like “get the day of the month from a Date” and such. The proper way to do this seemingly involves more types than you’d think is reasonable, but it’s that way for very good reasons.

I’d encourage people who want to know more about this to go read through http://yourcalendricalfallacyis.com <http://yourcalendricalfallacyis.com/&gt;, and I’d be happy to disabuse anyone of false calendrical notions on a new thread.

Cheers,

Dave

···

On Aug 1, 2017, at 9:14 AM, Taylor Swift via swift-evolution <swift-evolution@swift.org> wrote:

- Modern String processing toolkit
- 2D Graphics library (similar to cairo)
- Windowing/UI library

I think David Turnbull tried to get something like this started years back but it fizzled out pretty quick, probably because the Swift foss community was much smaller back then. Time to try again?

On Tue, Aug 1, 2017 at 8:29 AM, Georgios Moschovitis <george.moschovitis@icloud.com <mailto:george.moschovitis@icloud.com>> wrote:
> That's what's happened with the Server APIs Project
> https://swift.org/server-apis/
>
> I would like to see more of this, and math/BigNum seems like a good candidate.
>
> Another is a modern date/time package, standing on the shoulders of
> The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 310 <The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 310; and similar.

+ 1

I would also love to see standard implementation of Graph data structures, at least some common protocols.
Dunno why this versatile data structure is not included in standard libraries (similar to Map/Dictionary), Set, etc.

-g.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

31

I’ve noticed from this and older threads that everyone agrees on what core
libraries we want, but they never actually get built. Perennial requests
seem to be

- RNG and cryptography library (CryptoSwift could be a good base for this)
- Generic Math library/Vector library
- Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList,
graphs, etc)
- Modern DateTime library
- Modern String processing toolkit
- 2D Graphics library (similar to cairo)
- Windowing/UI library

I think David Turnbull tried to get something like this started years back
but it fizzled out pretty quick, probably because the Swift foss community
was much smaller back then. Time to try again?

···

On Tue, Aug 1, 2017 at 8:29 AM, Georgios Moschovitis < george.moschovitis@icloud.com> wrote:

> That's what's happened with the Server APIs Project
> https://swift.org/server-apis/
>
> I would like to see more of this, and math/BigNum seems like a good
candidate.
>
> Another is a modern date/time package, standing on the shoulders of
> The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 310 and similar.

+ 1

I would also love to see standard implementation of Graph data structures,
at least some common protocols.
Dunno why this versatile data structure is not included in standard
libraries (similar to Map/Dictionary), Set, etc.

-g.

32

Cool! When is this planned to implemented? Until then though, it’s probably
a good idea to design core libraries as submodules (preferably a single
file), not modules. You lose the ability to use the SPM to manage them, but
you don’t have to rummage through the files and change all the access
modifiers. Not ideal, but I’m glad this won’t be the situation forever.

···

On Tue, Aug 1, 2017 at 12:45 PM, Michael Ilseman <milseman@apple.com> wrote:

On Aug 1, 2017, at 8:02 AM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote:

I think the Server APIs project was pretty close to what I had in mind
actually. I don’t see why more core libraries can’t be commissioned that
way, things like Math and DateTime would probably draw a great deal more
attention than Server APIs since they are used by more people. One thing
that would have to be fixed though is the cross-module optimization
problem; no one in their right mind should ever be making generic calls to
sin(x). A feature in the SPM that would perform “injection” of core
library code into the interior of modules would probably be enough to fix
this problem for now. (If this sounds hacky just remember that right now
everyone seems to be copying and pasting .swift files everywhere.)
Everything internal would become fileprivate and everything public would
become internal. A good Swift library should expose no more than 7 or 8
symbols at the top level so this should play nice with most client projects.

This is already planned as part of how Modules will be able to control
what is and is not part of their ABI: Apple · GitHub
swift/blob/master/docs/LibraryEvolution.rst#inlineable-functions

On Tue, Aug 1, 2017 at 4:50 AM, Ian Partridge <ian@poncho.org.uk> wrote:

On 1 August 2017 at 04:46, Taylor Swift via swift-evolution >> <swift-evolution@swift.org> wrote:
> 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.

That's what's happened with the Server APIs Project
https://swift.org/server-apis/

I would like to see more of this, and math/BigNum seems like a good
candidate.

Another is a modern date/time package, standing on the shoulders of
The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 310 and similar.

--
Ian Partridge

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

33

I’ve noticed from this and older threads that everyone agrees on what core
libraries we want, but they never actually get built. Perennial requests
seem to be

- RNG and cryptography library (CryptoSwift could be a good base for this)

A new implementation of crypto is probably a very bad idea. A blessed
wrapping around the platform’s preferred implementation of crypto, however,
is certainly needed.

Good point, but then again CryptoSwift has already demonstrated a demand
for a new Swift implementation and we wouldn’t be starting from scratch.

- Generic Math library/Vector library

This is pretty compelling.

- Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList,
graphs, etc)

Which flavor/implementation of tree, balanced tree, heap, graphs are
desirable here? The desirability of many of these structures is often
dependent on which of many competing tradeoffs were made. Implementation
details can dramatically shape the general applicability of a data
structure.

For example, it might make sense to adopt something similar to
GitHub - attaswift/BTree: Fast sorted collections for Swift using in-memory B-trees as a general underlying representation
for some kinds of higher level collections (or the mechanisms to easily
adapt them).

The idea wouldn’t be to cover every possible permutation of these data
structures, but provide implementations for the most commonly used
varieties.

- Modern DateTime library

Foundation provides many of these, though I’m sure there are always
opportunities for improvement. Do you see a specific need that cannot be
addressed with improvements to corelibs-foundation? There’s a large amount
of domain expertise in Foundation and they are pretty active on the mailing
lists.

I’d be happy just with moving the datetime functionality from Foundation
into its own module. I’m really not a fan of the monolith pattern.

- Modern String processing toolkit

This is a huge gap in Swift’s current offerings, and I’m personally
invested in improving the situation here. At the risk of hijacking this
thread, do you have a good bullet list of the kinds of facilities you
imagine useful? More specifically (and to keep the discussion scoped), are
there any tools beyond something like good language support for regular
expression matching and substitutions?

Pretty basic but most of what you have to import Foundation to do right
now, plus a few extras.

- trim whitespace from a string
- string formatting
    - round float to n decimal places
    - pad float to n 0s
    - left/right/center pad string with spaces
- locale aware capitalization
- defined CharacterSetsfor things like alphabeticals, numerics, whitespace
chars, etc.
- regex support would be nice
- platform-abstracted terminal colors would be nice

plus a lot of things I’m probably forgetting

- 2D Graphics library (similar to cairo)

- Windowing/UI library

By this, do you mean cross-platform pure Swift rethinks? This is certainly
interesting, but a pure Swift rethink is likely a lower priority than
exposing bindings for existing cross-platform approaches (e.g. you
mentinoed cairo). Like crypto, it might make sense to establish blessed
wrappers/apinotes/overlays on top of tried-and-true open source offerings.

Currently, calling Cairo code from Swift is extremely problematic for
reasons involving memory ownership and object lifetimes. Nothing an
experienced Swift dev can’t get around, but definitely far too ugly a hack
for such a common task. The C library is simply incompatible with Swift’s
memory safety model.

···

On Tue, Aug 1, 2017 at 1:20 PM, Michael Ilseman <milseman@apple.com> wrote:

On Aug 1, 2017, at 8:14 AM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote:

I think David Turnbull tried to get something like this started years back
but it fizzled out pretty quick, probably because the Swift foss community
was much smaller back then. Time to try again?

On Tue, Aug 1, 2017 at 8:29 AM, Georgios Moschovitis < > george.moschovitis@icloud.com> wrote:

> That's what's happened with the Server APIs Project
> https://swift.org/server-apis/
>
> I would like to see more of this, and math/BigNum seems like a good
candidate.
>
> Another is a modern date/time package, standing on the shoulders of
> The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 310 and similar.

+ 1

I would also love to see standard implementation of Graph data
structures, at least some common protocols.
Dunno why this versatile data structure is not included in standard
libraries (similar to Map/Dictionary), Set, etc.

-g.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

34

I’ve noticed from this and older threads that everyone agrees on what core
libraries we want, but they never actually get built. Perennial requests
seem to be

- RNG and cryptography library (CryptoSwift could be a good base for this)

A new implementation of crypto is probably a very bad idea. A blessed
wrapping around the platform’s preferred implementation of crypto, however,
is certainly needed.

My understanding was that this is already part of the Swift server working
group’s efforts, and a large part at that.

- Generic Math library/Vector library

···

On Tue, Aug 1, 2017 at 12:21 Michael Ilseman via swift-evolution < swift-evolution@swift.org> wrote:

On Aug 1, 2017, at 8:14 AM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote:

This is pretty compelling.

- Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList,
graphs, etc)

Which flavor/implementation of tree, balanced tree, heap, graphs are
desirable here? The desirability of many of these structures is often
dependent on which of many competing tradeoffs were made. Implementation
details can dramatically shape the general applicability of a data
structure.

For example, it might make sense to adopt something similar to
GitHub - attaswift/BTree: Fast sorted collections for Swift using in-memory B-trees as a general underlying representation
for some kinds of higher level collections (or the mechanisms to easily
adapt them).

- Modern DateTime library

Foundation provides many of these, though I’m sure there are always
opportunities for improvement. Do you see a specific need that cannot be
addressed with improvements to corelibs-foundation? There’s a large amount
of domain expertise in Foundation and they are pretty active on the mailing
lists.

- Modern String processing toolkit

This is a huge gap in Swift’s current offerings, and I’m personally
invested in improving the situation here. At the risk of hijacking this
thread, do you have a good bullet list of the kinds of facilities you
imagine useful? More specifically (and to keep the discussion scoped), are
there any tools beyond something like good language support for regular
expression matching and substitutions?

- 2D Graphics library (similar to cairo)

- Windowing/UI library

By this, do you mean cross-platform pure Swift rethinks? This is certainly
interesting, but a pure Swift rethink is likely a lower priority than
exposing bindings for existing cross-platform approaches (e.g. you
mentinoed cairo). Like crypto, it might make sense to establish blessed
wrappers/apinotes/overlays on top of tried-and-true open source offerings.

I think David Turnbull tried to get something like this started years back
but it fizzled out pretty quick, probably because the Swift foss community
was much smaller back then. Time to try again?

On Tue, Aug 1, 2017 at 8:29 AM, Georgios Moschovitis < > george.moschovitis@icloud.com> wrote:

> That's what's happened with the Server APIs Project
> https://swift.org/server-apis/
>
> I would like to see more of this, and math/BigNum seems like a good
candidate.
>
> Another is a modern date/time package, standing on the shoulders of
> The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 310 and similar.

+ 1

I would also love to see standard implementation of Graph data
structures, at least some common protocols.
Dunno why this versatile data structure is not included in standard
libraries (similar to Map/Dictionary), Set, etc.

-g.

_______________________________________________
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

35

At the same time, people should be able to float ideas here to see how well
they would be received before investing the energy into writing up a
proposal. I certainly wouldn’t spend time drafting up an entire API spec
for a math library without first checking that this is something that the
community actually wants.

···

On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan < gor.f.gyolchanyan@icloud.com> wrote:

On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift <kelvin13ma@gmail.com> wrote:

On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution < >>> swift-evolution@swift.org> wrote:

On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution < >>>> swift-evolution@swift.org> wrote:

On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution < >>>>> swift-evolution@swift.org> wrote:

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.

I already opened a new mail to write my answer, but than I thought
"wait, scroll down, and look if Xiaodi did already post links" ;-)
[But where have those potential core libraries been mentioned?]

Anyways, my perception hasn't change much:
I think it would be enough if someone from Apple would say "here's an
empty github-repo called [math/statistics/algebra/crypt
o/graphic/image/audio/music/video/smtp/http…]; feel free to fork and
create pull requests" and adding some democratic mechanism for acceptance
on top of it.

What would be your compatibility and stability expectations of such
APIs? If there are any expectations, then the APIs would need careful
design and thought. The Swift project faces a lot of design bandwidth
limitations, so prioritize is always tricky.

The point of spinning off separate core library working groups would be
so that library feature requests and proposals can stop clogging up
swift-evolution. Then the swift-evolution core team could focus on the
compiler and the standard library and the community would take stewardship
of the core libraries through separate channels.

My understanding is that the server working group, and all such work
groups, will be presenting their proposals here for approval, and that all
API changes in the Swift open source project go through this list.

That sounds like it would spam the general list a lot?

On the contrary, core team members have confirmed that working proposals
such as those are the principal intended use for this list; it is *not*
meant to be a general forum for musings about Swift language design.

My rule of thumb was that any post on the mailing list that I make has to
be aimed at providing a solution to a problem, or at the very least,
seeking help in providing a solution to a problem. If the discussion has no
definitive actionable outcome, then I consider it pointless.

36

I would mostly agree with that statement, except for the word "here." Swift
Evolution clearly isn't representative of the community of Swift users
generally; there are Slack channels, Reddit groups, and other forums which
are intended to be a place for general discussion, and which would probably
get you a good sense of what users want. I definitely agree with Gor that
the "actionable outcome" rule of thumb is a pretty good guideline for
what's most effective on this mailing list.

The other point I'd make here is that I definitely think the core team is
right about encouraging any "entire API spec" for a math library to be
based on implementation experience from actually writing a math library
that has seen good adoption. Essentially, what they're saying is that any
proposed design here should have already proved itself in the field. I
assume that you are well aware of Conway's law, which afaict has good
evidence to back it up; with that in mind, the end product that emerges
from a draft spec and an empty open-source repo is unlikely to be
satisfactory, let alone optimal.

···

On Wed, Aug 2, 2017 at 12:23 PM, Taylor Swift <kelvin13ma@gmail.com> wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan < > gor.f.gyolchanyan@icloud.com> wrote:

On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote:

On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift <kelvin13ma@gmail.com> w
rote:

On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution < >>>> swift-evolution@swift.org> wrote:

On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution < >>>>> swift-evolution@swift.org> wrote:

On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution < >>>>>> swift-evolution@swift.org> wrote:

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.

I already opened a new mail to write my answer, but than I thought
"wait, scroll down, and look if Xiaodi did already post links" ;-)
[But where have those potential core libraries been mentioned?]

Anyways, my perception hasn't change much:
I think it would be enough if someone from Apple would say "here's an
empty github-repo called [math/statistics/algebra/crypt
o/graphic/image/audio/music/video/smtp/http…]; feel free to fork and
create pull requests" and adding some democratic mechanism for acceptance
on top of it.

What would be your compatibility and stability expectations of such
APIs? If there are any expectations, then the APIs would need careful
design and thought. The Swift project faces a lot of design bandwidth
limitations, so prioritize is always tricky.

The point of spinning off separate core library working groups would
be so that library feature requests and proposals can stop clogging up
swift-evolution. Then the swift-evolution core team could focus on the
compiler and the standard library and the community would take stewardship
of the core libraries through separate channels.

My understanding is that the server working group, and all such work
groups, will be presenting their proposals here for approval, and that all
API changes in the Swift open source project go through this list.

That sounds like it would spam the general list a lot?

On the contrary, core team members have confirmed that working proposals
such as those are the principal intended use for this list; it is *not*
meant to be a general forum for musings about Swift language design.

My rule of thumb was that any post on the mailing list that I make has to
be aimed at providing a solution to a problem, or at the very least,
seeking help in providing a solution to a problem. If the discussion has no
definitive actionable outcome, then I consider it pointless.

At the same time, people should be able to float ideas here to see how
well they would be received before investing the energy into writing up a
proposal. I certainly wouldn’t spend time drafting up an entire API spec
for a math library without first checking that this is something that the
community actually wants.

37

Oh, I know. I wasn't claiming that we need massive compiler changes right now or anything, just providing an example of a syntax that a hypothetical "CoreMath" type of library might want to support which can't currently be made into legal swift code.

- Dave Sweeris

···

On Aug 2, 2017, at 4:29 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Wed, Aug 2, 2017 at 6:17 PM, David Sweeris <davesweeris@mac.com> wrote:

Sent from my iPad
On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans <nicolas.fezans@gmail.com> wrote:
I think that the items mentioned earlier in the list (just reminded below) should not all be treated equally.

- RNG and cryptography library (CryptoSwift could be a good base for this)
- Generic Math library/Vector library
- Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList, graphs, etc)
- Modern DateTime library
- Modern String processing toolkit
- 2D Graphics library (similar to cairo)
- Windowing/UI library

By that I mean that I see at least one distinction to make between:

a) the libraries that would make Swift and the programmer experience with these libraries under Swift significantly better if they are (or at least feel) deeply integrated in the language (for instance with associated syntax / syntax sugar)
    and
b) those that would not really benefit from such an integration to the language.

For me a core math library, clearly belongs to category a)
I am of course not talking about a syntax sugar to call a sin or cos function, but rather to manipulate other objects such as N-dimensional matrices, defining maths functions that can take such matrices as argument e.g. sin(A) with A as matrix produces a matrix of the same size where all elements are the sinus values of the elements of A (sorry but things like this calling map() with 'sin' looks quite ugly for scientists).
Such a good math syntax should be compact enough to have complete equations looking "close enough" to the maths equations you could have written in a LaTeX or Word documentation of your scientific code. IMO a well integrated swift core math library should feel a Julia or Matlab code (while still having the power of Swift in terms of speed and modern programming paradigms) instead of looking and feeling like 'numpy'. But the latter is what you get if you just make a math library with no integration to the language syntax, operators, and basic functions.

I agree that if this would require compiler support, then it needs to be part of the standard library. However, I don't see anything about what you describe that cannot be supported as a third-party library.

Getting the syntax right could possibly require some compiler changes. Maybe. Depends on what "right" means. Declaring a variable, x, to be "the set of all real numbers such that x*sin(x) is an integer" using syntax like this, "let x = {x ∈ ℝ | x * sin(x) ∈ ℕ}", would be neat (I'm a bit hazy on my set notation... that might not actually be correct).
We're actually not that far off from that, compiler-wise, I mean. Aside defining the relevant types, operators, and identifiers, that exact syntax pretty much just requires the compiler to allow using a certain types of variables in their own declaration and either one heck of an `ExpressibleByClosureLiteral` protocol, or improvements to the type inference engine.

We must prioritize features that make the biggest impact for the general community, however. Swift still lacks ABI stability, ownership, concurrency, etc. In terms of math facilities, we still don't have a model for dealing with floating point errors. And, yes, there are improvements to be made in terms of having consistent special functions (sin, cos) in Swift (Glibc and Darwin don't always give you the same answer). All of these things represent sorely needed yet large undertakings; none of these require more syntax.

38

We must prioritize features that make the biggest impact for the general
community, however. Swift still lacks ABI stability, ownership,
concurrency, etc. In terms of math facilities, we still don't have a model
for dealing with floating point errors. And, yes, there are improvements to
be made in terms of having consistent special functions (sin, cos) in Swift
(Glibc and Darwin don't always give you the same answer). All of these
things represent sorely needed yet large undertakings; none of these
require more syntax.

···

On Wed, Aug 2, 2017 at 6:17 PM, David Sweeris <davesweeris@mac.com> wrote:

Sent from my iPad
On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans <nicolas.fezans@gmail.com> > wrote:

I think that the items mentioned earlier in the list (just reminded
below) should not all be treated equally.

- RNG and cryptography library (CryptoSwift could be a good base for this)
- Generic Math library/Vector library
- Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList,
graphs, etc)
- Modern DateTime library
- Modern String processing toolkit
- 2D Graphics library (similar to cairo)
- Windowing/UI library

By that I mean that I see at least one distinction to make between:

a) the libraries that would make Swift and the programmer experience with
these libraries under Swift significantly better if they are (or at least
feel) deeply integrated in the language (for instance with associated syntax
/ syntax sugar)
    and
b) those that would not really benefit from such an integration to the
language.

For me a core math library, clearly belongs to category a)
I am of course not talking about a syntax sugar to call a sin or cos
function, but rather to manipulate other objects such as N-dimensional
matrices, defining maths functions that can take such matrices as argument
e.g. sin(A) with A as matrix produces a matrix of the same size where all
elements are the sinus values of the elements of A (sorry but things like
this calling map() with 'sin' looks quite ugly for scientists).
Such a good math syntax should be compact enough to have complete
equations looking "close enough" to the maths equations you could have
written in a LaTeX or Word documentation of your scientific code. IMO a
well integrated swift core math library should feel a Julia or Matlab code
(while still having the power of Swift in terms of speed and modern
programming paradigms) instead of looking and feeling like 'numpy'. But the
latter is what you get if you just make a math library with no integration
to the language syntax, operators, and basic functions.

I agree that if this would require compiler support, then it needs to be
part of the standard library. However, I don't see anything about what you
describe that cannot be supported as a third-party library.

Getting the syntax right could possibly require some compiler changes.
Maybe. Depends on what "right" means. Declaring a variable, x, to be "the
set of all real numbers such that x*sin(x) is an integer" using syntax like
this, "let x = {x ∈ ℝ | x * sin(x) ∈ ℕ}", would be neat (I'm a bit hazy
on my set notation... that might not actually be correct).
We're actually not that far off from that, compiler-wise, I mean. Aside
defining the relevant types, operators, and identifiers, that exact syntax
pretty much just requires the compiler to allow using a certain types of
variables in their own declaration and either one heck of an
`ExpressibleByClosureLiteral` protocol, or improvements to the type
inference engine.

39

See, my problem with statements like this one, is that the answer “should
be supported as a third-party library” can also be interpreted as “not my
problem, go figure it out yourselves”. The idea that central entity can
only pay attention to what they want to, and the Community™ will magically
take care of the rest is one of the most pervasive, and untrue, myths about
open source. What’s worse, is that Swift has the benefit of hindsight, in
the form of many, many examples of languages that came before and fell
victim to this fallacy, and now have 15 competing “private” classes for
basic mathematical objects like *vectors*.

I agree that a core math library, for example, *could* in theory be
supported as a third-party library.

The core team has said that they're open to a core math library being part
of the Swift open source project; they just outlined that the _process_ for
doing so is best initiated with a third-party library as a starting point.

But this will never happen on its own, for reasons that I will reiterate
here:

- no one influential enough has bothered to jump start any such project

Karoly Lorentey has a wonderful, and quite mature, BigInt project: <
https://github.com/lorentey/BigInt&gt;\. Also, as I mentioned, I just started a
project for protocol-based additions to Swift's basic numeric types. These
are just two examples.

- there are no avenues to encourage members of the community to come
together and organize a project (look how this thread got derailed!)

You're welcome to join me in my endeavor to create a math library. I'd bet
Karoly feels the same way about his project.

- there is no “soft” infrastructure in place to support such collaboration
(look at the fuss over discourse and mailing list spam!)

The GitHub environment has excellent tools to support such collaboration,
IMO. For example:

Based on my experience implementing a library, I wrote a Gist to outline
some lessons learned and suggestions for improvement. Not only did the
document find an audience, these suggestions were in turn used to inform
core team-driven revisions to the integer protocols. As a result of these
revisions, it became possible to implement some initializers that could be
useful for people writing generic numeric algorithms. Recently, I submitted
a PR to the Swift project on GitHub to implement these initializers. Now,
everyone will be able to use them. Collaboration, positive feedback loop,
win-win for all involved.

Likewise, Karoly used his experience updating BigInt for Swift 4 to inform
certain improvements to the integer protocols. He implemented these
improvements in a series of PRs. Now, as a result of these developments,
Karoly's library will be better designed *and* everyone else will benefit
from a better implementation of the integer protocols. Again,
collaboration, positive feedback loop, win-win for all involved.

- there are no positive feedback loops whereby a promising project can gain

market share and mature
- because there is no organization backing these projects, potential users
are reluctant to depend on these libraries, since they will logically bet
that the library is more likely to fall out of maintenance than reach
maturity.

Addressing this point is clearly impossible. When Apple wishes to commit
its own resources to the maintenance of a Swift math library,
swift-corelibs-math will appear on GitHub. Suggestions such as opening an
empty repo and letting people contribute to it would either give the
illusion of organizational backing that doesn't exist or would in fact
commit Apple to support a repo that it doesn't wish to support. I fail to
see why the former is good for anybody; in fact, it's strictly inferior to
the same repo honestly representing itself as a third-party effort. And
asking for the latter is essentially asking Apple to create a Swift math
library--which, again, is not in the cards.

- everyone works on their own in-house “half-assed” implementation, and
people are not encouraged to come together and pool resources so instead
there is a lot of duplicated work

The beauty of open source is that you're also welcome to fork my project
instead of duplicating it from scratch; keep it licensed the same way and I
can pick and choose what to upstream. That's pooling resources right there.

···

On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift <kelvin13ma@gmail.com> wrote:

On Wed, Aug 2, 2017 at 6:42 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

I agree that if this would require compiler support, then it needs to be
part of the standard library. However, I don't see anything about what you
describe that cannot be supported as a third-party library.

40

Agreed. The problem with that is purely technical and will be resolved once the swift community migrates to discourse.
I alone have a myriad of thoughts and ideas and questions that would completely litter this mailing list, so I'm holding off until better times.

···

On Aug 2, 2017, at 8:23 PM, Taylor Swift <kelvin13ma@gmail.com> wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan <gor.f.gyolchanyan@icloud.com <mailto:gor.f.gyolchanyan@icloud.com>> wrote:

On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift <kelvin13ma@gmail.com <mailto:kelvin13ma@gmail.com>> wrote:

On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:

On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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.

I already opened a new mail to write my answer, but than I thought "wait, scroll down, and look if Xiaodi did already post links" ;-)
[But where have those potential core libraries been mentioned?]

Anyways, my perception hasn't change much:
I think it would be enough if someone from Apple would say "here's an empty github-repo called [math/statistics/algebra/crypto/graphic/image/audio/music/video/smtp/http…]; feel free to fork and create pull requests" and adding some democratic mechanism for acceptance on top of it.

What would be your compatibility and stability expectations of such APIs? If there are any expectations, then the APIs would need careful design and thought. The Swift project faces a lot of design bandwidth limitations, so prioritize is always tricky.

The point of spinning off separate core library working groups would be so that library feature requests and proposals can stop clogging up swift-evolution. Then the swift-evolution core team could focus on the compiler and the standard library and the community would take stewardship of the core libraries through separate channels.

My understanding is that the server working group, and all such work groups, will be presenting their proposals here for approval, and that all API changes in the Swift open source project go through this list.

That sounds like it would spam the general list a lot?

On the contrary, core team members have confirmed that working proposals such as those are the principal intended use for this list; it is *not* meant to be a general forum for musings about Swift language design.

My rule of thumb was that any post on the mailing list that I make has to be aimed at providing a solution to a problem, or at the very least, seeking help in providing a solution to a problem. If the discussion has no definitive actionable outcome, then I consider it pointless.

At the same time, people should be able to float ideas here to see how well they would be received before investing the energy into writing up a proposal. I certainly wouldn’t spend time drafting up an entire API spec for a math library without first checking that this is something that the community actually wants.