> On Nov 7, 2017, at 5:54 PM, 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.
Hi Dave, As others have pointed out, we do already have a model for this sort of thing: the swift server working group. 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. 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. -Chris _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
