[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift]

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/
>>> 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? Wouldn’t a more
decentralized model mitigate the “we don’t have the energy/attention to
devote to this” complaint?

Also as a gauge of interest, I’m wondering who here would like to work on a
core library if a campaign to build some was started now.


>
> But as long as no one with enough reputation starts Swifts equivalent of
>>> boost, there won't be a set of established libraries for basic data
>>> structures and algorithms outside the stdlib.
>>>
>>> For anyone who thinks there's no need for a standard lib that is not the
>>> stdlib, have a look at
>>> https://developer.apple.com/documentation/glkit/glkquaternion-pc6
>>> https://developer.apple.com/documentation/scenekit/scnquaternion
>>> https://developer.apple.com/documentation/coremotion/cmquaternion
>>> :-(
>>>
>>> Tino
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170801/0299509b/attachment.html>