On Wed, Aug 2, 2017 at 12:23 PM, Taylor Swift <[email protected]> wrote:
> > > On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan < > [email protected]> wrote: > >> >> 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]> w >> rote: >> >>> >>> >>> On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <[email protected]> wrote: >>> >>>> >>>> On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution < >>>> [email protected]> wrote: >>>> >>>>> On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution < >>>>>> [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/crypt >>>>>> o/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. > I would mostly agree with that statement, except for the word "here." Swift Evolution clearly isn't representative of the community of Swift users generally; there are Slack channels, Reddit groups, and other forums which are intended to be a place for general discussion, and which would probably get you a good sense of what users want. I definitely agree with Gor that the "actionable outcome" rule of thumb is a pretty good guideline for what's most effective on this mailing list. The other point I'd make here is that I definitely think the core team is right about encouraging any "entire API spec" for a math library to be based on implementation experience from actually writing a math library that has seen good adoption. Essentially, what they're saying is that any proposed design here should have already proved itself in the field. I assume that you are well aware of Conway's law, which afaict has good evidence to back it up; with that in mind, the end product that emerges from a draft spec and an empty open-source repo is unlikely to be satisfactory, let alone optimal.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
