[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Xiaodi Wu]

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.


> 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/0d063c53/attachment.html>