[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Xiaodi Wu]

On Wed, Aug 2, 2017 at 12:23 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:

>
>
> On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan <
> gor.f.gyolchanyan at icloud.com> wrote:
>
>>
>> On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift <kelvin13ma at gmail.com> w
>> rote:
>>
>>>
>>>
>>> On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>
>>>>
>>>> On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>>> On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution <
>>>>> swift-evolution at swift.org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution <
>>>>>> swift-evolution at swift.org> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170802/3ceae8e0/attachment.html>