> On Nov 7, 2017, at 3:12 PM, David Sweeris <daveswee...@mac.com> wrote:
>
>>
>> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@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
>> <http://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.
Dave
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
