[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Gor Gyolchanyan]

> On Aug 2, 2017, at 8: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 <mailto: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 <mailto:swift-evolution at swift.org>> wrote:
>> 
>> On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift <kelvin13ma at gmail.com <mailto:kelvin13ma at gmail.com>> wrote:
>> 
>> 
>> On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>> 
>> On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution <swift-evolution at swift.org <mailto: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/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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170802/d117b549/attachment.html>