<div dir="ltr"><div>I think that the items mentioned earlier in the list (just reminded below) should not all be treated equally.<br></div><div><br></div><div><div style="font-size:12.800000190734863px"><div><div><div><div>- RNG and cryptography library (CryptoSwift could be a good base for this)<br></div>- Generic Math library/Vector library<br></div>- Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList, graphs, etc)<br></div>- Modern DateTime library<br></div><div>- Modern String processing toolkit<br></div>- 2D Graphics library (similar to cairo)<br></div><span style="font-size:12.800000190734863px">- Windowing/UI library</span><br></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">By that I mean that I see at least one distinction to make between:</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">a) the libraries that would make Swift and the programmer experience with these libraries under Swift significantly better if they are (or at least feel) deeply integrated in the language (for instance with associated </span><span style="font-size:12.800000190734863px">syntax / </span><span style="font-size:12.800000190734863px">syntax sugar)</span></div><div><span style="font-size:12.800000190734863px"> and </span></div><div><span style="font-size:12.800000190734863px">b) those that would not really benefit from such an integration to the language.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">For me a core math library, clearly belongs to category a)</span></div><div><span style="font-size:12.800000190734863px">I am of course not talking about a syntax sugar to call a sin or cos function, but rather to manipulate other objects such as N-dimensional matrices, defining maths functions that can take such matrices as argument e.g. sin(A) with A as matrix produces a matrix of the same size where all elements are the sinus values of the elements of A (sorry but things like this calling map() with 'sin' looks quite ugly for scientists).</span></div><div><span style="font-size:12.800000190734863px">Such a good math syntax should be compact enough to have complete equations looking "close enough" to the maths equations you could have written in a LaTeX or Word documentation of your scientific code. IMO a well integrated swift core math library should feel a Julia or Matlab code (while still having the power of Swift in terms of speed and modern programming paradigms) instead of looking and feeling like 'numpy'. But the latter is what you get if you just make a math library with no integration to the language syntax, operators, and basic functions.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">I would personally place a crypto library in category b).</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">For basic data structures, I would say probably something in between: maybe a few data structures are worth having a nicer syntax that typical method calls (just as [] are used for arrays and it looks and feels great) but it would be pointless IMHO to try extending that to too many of these data structures.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 2, 2017 at 11:08 PM, Xiaodi Wu via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Aug 2, 2017 at 12:23 PM, Taylor Swift <span dir="ltr"><<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan <span dir="ltr"><<a href="mailto:gor.f.gyolchanyan@icloud.com" target="_blank">gor.f.gyolchanyan@icloud.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-1129980757426228621m_5909788958951470175m_2858378366605496948Apple-interchange-newline"><div><div dir="ltr" style="font-family:AvenirNext-Regular;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift<span class="m_-1129980757426228621m_5909788958951470175m_2858378366605496948Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>></span><span class="m_-1129980757426228621m_5909788958951470175m_2858378366605496948Apple-converted-space"> </span>w<wbr>rote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu<span class="m_-1129980757426228621m_5909788958951470175m_2858378366605496948Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span><span class="m_-1129980757426228621m_5909788958951470175m_2858378366605496948Apple-converted-space"> </span>wrote<wbr>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><br><div class="gmail_quote"><span><div dir="auto">On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution<span class="m_-1129980757426228621m_5909788958951470175m_2858378366605496948Apple-converted-space"> </span><span><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evoluti<wbr>on@swift.org</a>></span><span class="m_-1129980757426228621m_5909788958951470175m_2858378366605496948Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><br><blockquote type="cite"><div>On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-1129980757426228621m_5909788958951470175m_2858378366605496948m_-1917524409364692562m_-4924076454539159552m_8787000945925146662m_-949640947313699542Apple-interchange-newline"><div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">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.</div></div></blockquote></div>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" ;-)<div>[But where have those potential core libraries been mentioned?]</div><div><br></div><div>Anyways, my perception hasn't change much:</div><div>I think it would be enough if someone from Apple would say "here's an empty github-repo called [math/statistics/algebra/crypt<wbr>o/graphic/image/audio/music/vi<wbr>deo/smtp/http…]; feel free to fork and create pull requests" and adding some democratic mechanism for acceptance on top of it.</div><div><br></div></div></div></blockquote><div><br></div></span><div>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.</div><div><br></div></div></div></blockquote><div><br></div></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div></blockquote><div dir="auto"><br></div></span><div dir="auto">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.</div></div></div></blockquote><div><br></div></span><div>That sounds like it would spam the general list a lot?</div></div></div></div></blockquote><div><br></div><div>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.</div><div> </div></div></div></div></div></blockquote><div><br></div></span><div>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.</div></div></div></blockquote></div><br></div></span><div class="gmail_extra">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.<br></div></div></blockquote><div><br></div></div></div><div>I would mostly agree with that statement, except for the word "here." Swift Evolution clearly isn't representative of the community of Swift users generally; there are Slack channels, Reddit groups, and other forums which are intended to be a place for general discussion, and which would probably get you a good sense of what users want. I definitely agree with Gor that the "actionable outcome" rule of thumb is a pretty good guideline for what's most effective on this mailing list.</div><div><br></div><div>The other point I'd make here is that I definitely think the core team is right about encouraging any "entire API spec" for a math library to be based on implementation experience from actually writing a math library that has seen good adoption. Essentially, what they're saying is that any proposed design here should have already proved itself in the field. I assume that you are well aware of Conway's law, which afaict has good evidence to back it up; with that in mind, the end product that emerges from a draft spec and an empty open-source repo is unlikely to be satisfactory, let alone optimal.</div></div><br></div></div>
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>