[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Gor Gyolchanyan gor.f.gyolchanyan at icloud.com
Wed Aug 2 11:45:45 CDT 2017


> 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 <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.

> 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/glkit/glkquaternion-pc6>
>> https://developer.apple.com/documentation/scenekit/scnquaternion <https://developer.apple.com/documentation/scenekit/scnquaternion>
>> https://developer.apple.com/documentation/coremotion/cmquaternion <https://developer.apple.com/documentation/coremotion/cmquaternion>
>> :-(
>> 
>> Tino
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/a909ae65/attachment.html>


More information about the swift-evolution mailing list