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

[Ted Kremenek]

> On Nov 8, 2017, at 11:49 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Nov 7, 2017, at 5:54 PM, 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.
> 
> Hi Dave,
> 
> As others have pointed out, we do already have a model for this sort of thing: the swift server working group. 

Hi Chris,

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.

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.

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

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.

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

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.

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.

Ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171109/6c179cae/attachment.html>