[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift]

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> wrote:
>
>>
>>
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170802/e9057d83/attachment.html>