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

[Kelvin Ma]

On Thu, Nov 9, 2017 at 1:49 AM, 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.
>

i feel like the swift server working group is something that is very
difficult to reproduce because in 3 years of Swift it’s the only example of
such a project in existence


>
> 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.
>
>
the problem is boost doesn’t ship with C++ so people view it as just
another dependency, kind of like jQuery but more annoying because you have
to clone and build this giant support library (at least that was my
experience building Blender back in 2012). the C++ STL library or the
python support modules are probably closer to the distribution model I’d
like to see


> 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171109/1a390330/attachment.html>