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.
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.
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.
Recruit a core team, a small group responsible for strategic direction, pulled
from experienced members well versed in contributing to Swift-dev.
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.
Build a Non-Standard Swift Evolution repository home.
Adopt a code license, based on Swift's current licensing.
Define the community working group rules and code of conduct.
Establish a mailing list and/or forum.
Begin the selection of target sublibraries and populating them by recruiting
committers and contributors.
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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
