> On Aug 2, 2017, at 8:23 PM, Taylor Swift <[email protected]> wrote: > > > > On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan > <[email protected] <mailto:[email protected]>> wrote: > >> On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution >> <[email protected] <mailto:[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. > > At the same time, people should be able to float ideas here to see how well > they would be received before investing the energy into writing up a > proposal. I certainly wouldn’t spend time drafting up an entire API spec for > a math library without first checking that this is something that the > community actually wants.
Agreed. The problem with that is purely technical and will be resolved once the swift community migrates to discourse. I alone have a myriad of thoughts and ideas and questions that would completely litter this mailing list, so I'm holding off until better times.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
