[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[T.J. Usiyan]

A thousand times yes to this.

On Tue, Aug 1, 2017 at 9:35 PM, 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.
>
>
>> 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
>>>>
>>>
>>
>
> _______________________________________________
> 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/20170802/c72e9e62/attachment.html>