<div dir="ltr"><div>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:<br><br><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/007815.html" target="_blank">https://lists.swift.org/<wbr>pipermail/swift-evolution/<wbr>Week-of-Mon-20160125/007815.<wbr>html</a><br><br><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038401.html" target="_blank">https://lists.swift.org/<wbr>pipermail/swift-evolution/<wbr>Week-of-Mon-20170731/038401.<wbr>html</a><br><br></div>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.<br><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 7, 2017 at 11:54 AM, Dave DeLong via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Hi Swift-Evolution,<br><br>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.<br><br>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.<br><br>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.<br><br><b>Mission Statement</b><br><br>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.<br><br><b>Goals</b><br><br>The main goals of this effort would be:<br><div><ul><li>Alleviate pressure on the Core Team while providing the developer community with functionality that normally falls under Apple's internal development umbrella.</li><li>Deliver authoritative, reliable, and regularly updated libraries avoiding issues faced by third-party dependencies.</li><li>Provide oversight, organization, and full community involvement to ensure its components are worthy, maintained, and passing a bar of need and excellence.</li></ul></div><b>Suggested Libraries</b><br><br>There are several areas we think that are ripe for improvement and implementation as a non-standard library, such as (but not limited to):<br><div><ul><li>A BigNum library</li><li>A full-featured Random library</li><li>A simplified date/time library</li><li>A library for manipulating paths (that is not based on URL or String)</li><li>An expanded Swift-native Geometry library and so forth.</li></ul></div></div></blockquote><div>Random is currently being discussed for inclusion into the stdlib. I’m currently <a href="https://github.com/kelvin13/url">developing</a> a modern URI type to replace the Foundation type.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">The scope and extent of the sublibraries would be proposed and debated on a parallel Non-Standard Library Evolution development list.<br><br><b>Coordination</b><br><br>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. <br></div></blockquote><div><br></div><div>I love Apple but is Apple oversight really going to be beneficial enough to warrant the additional bureaucratic overhead? <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><b>Next Steps</b><br><br>To proceed, we need a general community consensus that this effort is worth the significant overhead it would involve.<br><br>We must then:<br><div><ul><li>Select a project lead, who appoints technical leaders from the community.</li></ul></div></div></blockquote><div>Yes <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><ul><li>Recruit a core team, a small group responsible for strategic direction, pulled from experienced members well versed in contributing to Swift-dev.</li></ul></div></div></blockquote><div>Yes <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><ul><li>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.</li></ul></div></div></blockquote><div>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.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><ul><li>Build a Non-Standard Swift Evolution repository home.</li></ul></div></div></blockquote><div>Yes, and might I add this is a lot more important than most people seem to acknowledge. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><ul><li>Adopt a code license, based on Swift's current licensing.</li></ul></div></div></blockquote><div>Yes <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><ul><li>Define the community working group rules and code of conduct.</li></ul></div></div></blockquote><div>Yes. Since these libraries are meant to replace large parts of Foundation, we should probably ban Foundation imports.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><ul><li>Establish a mailing list and/or forum.</li></ul></div></div></blockquote><div>Sure <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><ul><li>Begin the selection of target sublibraries and populating them by recruiting committers and contributors.</li></ul></div></div></blockquote><div>Yep<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><b>Alternative Names</b><br><br>Suggested names for this effort include the following.<br><div><ul><li>Extended-Standard Library</li><li>Community-Standard Library</li><li>Non-Standard Library</li></ul></div>We are not married to any of these names and welcome alternative suggestions.<br><br><b>Measures of Success</b><br><br>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.<div><br></div><div>Thanks,</div><div><br></div><div>Dave DeLong and Erica Sadun</div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>