> On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift <[email protected] > <mailto:[email protected]>> wrote: > > > On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <[email protected] > <mailto:[email protected]>> wrote: > > On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > > >> On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >>> So, this has been discussed before on the list many times in the past. The >>> core team has stated that their preferred process for this is to have >>> individuals write their own libraries, get real-world adoption, then (as >>> consensus emerges) propose their inclusion as a core library. >> I already opened a new mail to write my answer, but than I thought "wait, >> scroll down, and look if Xiaodi did already post links" ;-) >> [But where have those potential core libraries been mentioned?] >> >> Anyways, my perception hasn't change much: >> I think it would be enough if someone from Apple would say "here's an empty >> github-repo called >> [math/statistics/algebra/crypto/graphic/image/audio/music/video/smtp/http…]; >> feel free to fork and create pull requests" and adding some democratic >> mechanism for acceptance on top of it. >> > > What would be your compatibility and stability expectations of such APIs? If > there are any expectations, then the APIs would need careful design and > thought. The Swift project faces a lot of design bandwidth limitations, so > prioritize is always tricky. > > > The point of spinning off separate core library working groups would be so > that library feature requests and proposals can stop clogging up > swift-evolution. Then the swift-evolution core team could focus on the > compiler and the standard library and the community would take stewardship of > the core libraries through separate channels. > > My understanding is that the server working group, and all such work groups, > will be presenting their proposals here for approval, and that all API > changes in the Swift open source project go through this list. > > That sounds like it would spam the general list a lot? > > On the contrary, core team members have confirmed that working proposals such > as those are the principal intended use for this list; it is *not* meant to > be a general forum for musings about Swift language design. >
My rule of thumb was that any post on the mailing list that I make has to be aimed at providing a solution to a problem, or at the very least, seeking help in providing a solution to a problem. If the discussion has no definitive actionable outcome, then I consider it pointless. > Wouldn’t a more decentralized model mitigate the “we don’t have the > energy/attention to devote to this” complaint? > > Also as a gauge of interest, I’m wondering who here would like to work on a > core library if a campaign to build some was started now. > > > >> But as long as no one with enough reputation starts Swifts equivalent of >> boost, there won't be a set of established libraries for basic data >> structures and algorithms outside the stdlib. >> >> For anyone who thinks there's no need for a standard lib that is not the >> stdlib, have a look at >> https://developer.apple.com/documentation/glkit/glkquaternion-pc6 >> <https://developer.apple.com/documentation/glkit/glkquaternion-pc6> >> https://developer.apple.com/documentation/scenekit/scnquaternion >> <https://developer.apple.com/documentation/scenekit/scnquaternion> >> https://developer.apple.com/documentation/coremotion/cmquaternion >> <https://developer.apple.com/documentation/coremotion/cmquaternion> >> :-( >> >> Tino >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
