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

[Ted Kremenek]

> On Nov 7, 2017, at 2:14 PM, Dave DeLong <swift at davedelong.com> wrote:
> 
> 
> 
>>> On Nov 7, 2017, at 3:12 PM, David Sweeris <davesweeris at mac.com> wrote:
>>> 
>>> 
>>> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> Hi Dave,
>>> 
>>> Thanks for bringing up this topic.  This has been kicked around a little, and we’re still exploring different models on how to extend Swift.
>>> 
>>> The server APIs work group is one operational model for the community to build out a new set of core libraries.  That work group was formed out of the observation that there were different implementations of the same thing being created by different Swift on server efforts, and that those different efforts should pool those resources together and standardize on some fundamentals.
>>> 
>>> That analogy could work here.  However, it also has possible major downsides.  It can be heavyweight, and also artificially raise the importance of certain people’s library efforts over others by creating a formal work group whose efforts are expected to eventually be incorporated into the core Swift distribution.  It would also force a discussion up front of what even makes sense to incorporate into the core Swift distribution, which might be artificially constraining the exploration of the set of libraries to implement.
>>> 
>>> I need to think about your idea more, but my first reaction is that my preferred route is that the community builds these libraries, ideally using Swift Packages, and through trial and use we evaluate those libraries and then decide if they should be incorporated as part of the core distribution.  There’s many factors involved in deciding if they can be incorporated into the core distribution, but all of those could be informed by actually building libraries and see them getting used.
>>> 
>>> We could also figure out a way to possibly highlight these efforts to the Swift community, maybe on swift-evolution or other means — but all with the expectation that these libraries are not *necessarily* going to be standardized as part of the core swift distribution.  I don’t think that’s all that bad either; not every library will make sense to incorporate into the core Swift distribution (e.g., they are highly domain specific) but still supporting their development would be beneficial to the community.
>>> 
>>> Note that any change going into the Swift core distribution inevitably involves swift-evolution and the core team.  Changes going into the core Swift distribution must meet a very high bar as far as implementation and design, the confidence we have into committing to specific APIs (especially since we’ll have ABI stability in Swift 5), and other factors.  Thus this will not really alleviate much burden on the Core team or on the community — one of the core goals of your proposal.  Further, incorporating all those concerns up front when building libraries might be counterproductive.
>>> 
>>> FWIW, Ben Cohen and I have been talking about possibly using Swift packages as a way to seed out experimental ideas for extensions to the Standard Library.  This would allow ideas to be trialed by real usage (a complaint I’ve seen about some changes we’ve made to Swift in the past).  Users could build things on top of those libraries, knowing they are available as packages, and if an API “graduates” to being part of the Standard Library the user can then depend upon it being available there.  If it never graduates, however, the package remains around.
>>> 
>>> One thing that resonates me in what you propose is about having a “well-organized effort” whose aim is to make these libraries feel cohesive and implemented well.  However, given that many of these naturally fall somewhere in the spectrum of responsibilities within the Standard Library and Foundation, I think it is self-misleading to think that the Core Team or others would not be involved in these efforts if the intention is to possibly incorporate these one day into the core Swift distribution.  There also may be other ways to achieve that level of cohesion in API design, such as through community discussion (possibly via the Swift.org mailing lists/forums).  This discussion would not necessarily be the same as the path to “ratification” of a library into core Swift, but a step that could benefit many library authors (including considering ideas one day incorporated into the core swift).  With such a mechanism many library authors could benefit even if they do not intend to have the library as part of the core distribution.
>>> 
>>> My apologies that these are all hand-wavy ideas, but I’m trying to paint a possible alternative way to achieve your goal of more library evolution for Swift without having such a formal work group that may be too heavy weight or too narrowly focused.
>> 
>> FWIW, I don't think it much matters if they get rolled into the "core" Swift distribution or library... I think all that's really necessary (well, to the extent that any of this is) is just to have an easy way to search for & install packages. Even just having the commonly used ones bundled into a "not quite standard library" that's a separate download would be icing on the cake, IMHO, because it makes it easy to find them and know that with them being widely used, they're probably at least reasonably fit for purpose.
>> 
>> - Dave Sweeris
> 
> As I see it, a “non-standard” library would be present on systems already; you wouldn’t have to bundle it inside your app like you would a third-party library.
> 
> But, maybe that’s too high a bar to set, because any library doing that has to start worrying about binary compatibility, in addition to source compatibility.

Right, and that would be the case with anything that is actually vended as part of the core distribution.  I’d like to see more great libraries being built that have high value to the community without having to have this artificially high bar set from the onset.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171107/12fab43c/attachment.html>