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@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@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