<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 8, 2017, at 11:49 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">On Nov 7, 2017, at 5:54 PM, Dave DeLong via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Hi Swift-Evolution,<br class=""><br class="">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 class=""><br class="">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 class=""><br class="">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 class=""></blockquote><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Hi Dave,</span><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">As others have pointed out, we do already have a model for this sort of thing: the swift server working group.<span class="Apple-converted-space"> </span></span><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div class="">Hi Chris,</div><div class=""><br class=""></div><div class="">While it is true we have the Swift server work group, it’s not clear that should be the default prototype model to follow here.</div><div class=""><br class=""></div><div class="">That work group was created with a specific purpose to help unify different efforts in the Swift on server community to establish a base set of fundamentals they all could rely upon. But that was after there was already various library implementations/server frameworks in use that could be looked upon to inform technical decisions. The work group is also a fairly heavyweight model; it is appropriate in many contexts but not all of them.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">That said, there is another analogy which gets closer to what you’re asking for: the Boost community for C++. Boost was formed because the C++ committee was too bogged down an wasn’t receptive to major library changes (at one point in time). Boost has effectively parallel leadership from the C++ committee (though individuals are involved in both organizations of course). This allows Boost to move faster, ship code, and get experience with it.</span><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">One of the specifically nice things about Boost is that they (at least originally) focused on building out ideas, getting experience with them, and then bringing the libraries back to the standard. The libraries occasionally undergo significant change when they are standardized, but the usage experience is unmatchable, particularly for very large and complex APIs.</span><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>This “getting experiences with them” model is what appeals to me most about Boost, and is more-or-less what I was suggesting in my earlier reply on this thread as an important ingredient when considering how to extend “core Swift”. The Swift server work group in many ways already follows this model, as it is drawing from other technical work from efforts such as Kitura, Vapor, etc.</div><br class=""><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">In the context of Swift, I think this sort of model could be very interesting, because there are really several different independent things going on: for a type like BigNum (for example) there are all the details of the implementation and design on the one hand, but then there is also the question of WHICH library it should ship with (Foundation or Swift or something else). That second decision is much easier to make after the community has converged on a specific design.</span></div></blockquote><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">In any case, I think it would be a bad move for the official Swift distributions to ship code that hasn’t been through the evolution process. The idea of the Server working group is to delegate detailed design and iteration to a team of experts, but then have them bring back the API to evolution when the iteration is done and it is time to “standardize” it. I think that this is a good model.</span></div></blockquote><br class=""></div><div>The question in my mind is whether a “work group” is the right default model here. It may be too heavyweight in many cases and perhaps not necessary for smaller efforts or efforts that involve less people.</div><div><br class=""></div><div>Also, the server work group has a preconceived plan that the libraries are added to “core Swift”, or in some way become an official part of Swift. I don’t think that needs to be an upfront goal for all Swift libraries out there. The analogy for Boost is interesting; while Boost is a proving ground for many ideas that eventually make it back to the C++ standard, not all of those APIs have that fate and that seems fine too.</div><div><br class=""></div><div>Ted</div></body></html>