[swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma]

This is something I have been pushing for for some time now and I am glad
to see some more force behind it. There are multiple prior threads about
this topic you should probably familiarize yourselves with for background:

https://lists.swift.org/pipermail/swift-evolution/
Week-of-Mon-20160125/007815.html

https://lists.swift.org/pipermail/swift-evolution/
Week-of-Mon-20170731/038401.html

Since it looks like cross-module inlining/specialization is slated for
Swift 5 I believe now is a good time to get such an effort started as this
was really the only *technical* barrier preventing such libraries from
being written in the past.


On Tue, Nov 7, 2017 at 11:54 AM, Dave DeLong via swift-evolution <
swift-evolution at swift.org> wrote:

> Hi Swift-Evolution,
>
> The Standard Library's goal is to be small and targeted. However, many
> aspects of Apple-provided frameworks need or offer opportunities for
> improvement or wholesale replacement. These enhancements lie beyond the
> scope of the Standard Library.
>
> To address this, we'd like to propose the idea of a "Non-Standard
> Library"; this would be a library that ships with a regular installation of
> Swift, but is not imported into .swift files by the compiler, unless
> explicitly requested by the developer.
>
> We are proposing a well-organized effort to parallel the Standard Library
> without putting additional implementation responsibilities onto the core
> team. This effort would mitigate what we see as platform-independent
> requirements that provide native Swift implementations that aren't
> burdened by Apple history.
>
> *Mission Statement*
>
> We propose to create an open-sourced "Non-Standard Library" effort that
> coexists with, coordinates with, and is blessed by the open source Swift
> development community. The "Non-Standard Library" will offer a
> well-curated, high-value collection of routines, types, and documentation
> to support Swift development on all platforms.
>
> *Goals*
>
> The main goals of this effort would be:
>
>    - Alleviate pressure on the Core Team while providing the developer
>    community with functionality that normally falls under Apple's internal
>    development umbrella.
>    - Deliver authoritative, reliable, and regularly updated libraries
>    avoiding issues faced by third-party dependencies.
>    - Provide oversight, organization, and full community involvement to
>    ensure its components are worthy, maintained, and passing a bar of need and
>    excellence.
>
> *Suggested Libraries*
>
> There are several areas we think that are ripe for improvement and
> implementation as a non-standard library, such as (but not limited to):
>
>    - A BigNum library
>    - A full-featured Random library
>    - A simplified date/time library
>    - A library for manipulating paths (that is not based on URL or String)
>    - An expanded Swift-native Geometry library and so forth.
>
> Random is currently being discussed for inclusion into the stdlib. I’m
currently developing <https://github.com/kelvin13/url> a modern URI type to
replace the Foundation type.


> The scope and extent of the sublibraries would be proposed and debated on
> a parallel Non-Standard Library Evolution development list.
>
> *Coordination*
>
> This effort would be fully coordinated with the Swift development team,
> respecting the team's existing commitments and responsibilities. We would
> request an Apple body to act as an official coordinator, enabling both
> oversight of this effort and to expose Apple-sourced suggestions to
> the Non-Standard community for action.
>

I love Apple but is Apple oversight really going to be beneficial enough to
warrant the additional bureaucratic overhead?


>
> *Next Steps*
>
> To proceed, we need a general community consensus that this effort is
> worth the significant overhead it would involve.
>
> We must then:
>
>    - Select a project lead, who appoints technical leaders from the
>    community.
>
> Yes

>
>    - Recruit a core team, a small group responsible for strategic
>    direction, pulled from experienced members well versed in contributing to
>    Swift-dev.
>
> Yes

>
>    - Establish a Non-Standard Swift Evolution process, based on the one
>    that is currently followed by Swift Evolution. Following SE practices will
>    guarantee a consistent and excellent language experience for those
>    developers including the Non-Standard library into their projects.
>
> I disagree. Swift evolution is incredibly brittle and bureaucratic, it
only works for the stdlib because it is relatively small and most of it has
already been solidified. Any non-standard library initiative would easily
overwhelm the bandwidth of a mailing list. Project leads should have
considerably more autonomy than for the stdlib.

>
>    - Build a Non-Standard Swift Evolution repository home.
>
> Yes, and might I add this is a lot more important than most people seem to
acknowledge.

>
>    - Adopt a code license, based on Swift's current licensing.
>
> Yes

>
>    - Define the community working group rules and code of conduct.
>
> Yes. Since these libraries are meant to replace large parts of Foundation,
we should probably ban Foundation imports.

>
>    - Establish a mailing list and/or forum.
>
> Sure

>
>    - Begin the selection of target sublibraries and populating them by
>    recruiting committers and contributors.
>
> Yep


> *Alternative Names*
>
> Suggested names for this effort include the following.
>
>    - Extended-Standard Library
>    - Community-Standard Library
>    - Non-Standard Library
>
> We are not married to any of these names and welcome alternative
> suggestions.
>
> *Measures of Success*
>
> A successful Non-Standard Library will provide a stable and incrementally
> grown ecology of Swift frameworks that developers can depend upon with a
> minimum of turbulence and regret cycles. For that reason, the most
> successful content will be core functionality, with significant field
> testing prior to adoption. We recommend that NSSE follow a model of
> provisionary adoption and refinement before deployment to ensure any
> adopting code base will not be affected by later module changes.
>
> Thanks,
>
> Dave DeLong and Erica Sadun
>
> _______________________________________________
> 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/20171107/2f9a306d/attachment.html>