<div dir="ltr">On Mon, May 1, 2017 at 11:47 PM, Rod Brown <span dir="ltr"><<a href="mailto:rodney.brown6@icloud.com" target="_blank">rodney.brown6@icloud.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><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 class=""><blockquote type="cite"><div>On 2 May 2017, at 2:33 pm, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_489130907280010425Apple-interchange-newline"><div><div dir="ltr">On Mon, May 1, 2017 at 11:22 PM, T.J. Usiyan <span dir="ltr"><<a href="mailto:griotspeak@gmail.com" target="_blank">griotspeak@gmail.com</a>></span> wrote:<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">Xi: "Does this gain something by being part of the standard library?"<div>Me: "<span style="font-size:12.800000190734863px">This gains discoverability and standardization by being part of the standard library."</span></div><div><span style="font-size:12.800000190734863px">Xi: "</span><span style="font-size:12.800000190734863px">By definition, if it's in the standard library, it becomes standardized and discoverable.</span><span style="font-size:12.800000190734863px">"</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">We're in agreement, then?</span></div></div></blockquote><div><br></div><div>No, you're missing the point entirely. Again, _anything_ gains "discoverability and standardization" by being included as part of the standard library. However, the standard library is deliberately small and is intended to stay that way. So, what should be in and what should be out? The question is: does this feature gain something by being part of the standard library which other features that are deliberately excluded (like left pad) do not?</div></div></div></div></div></blockquote><div><br></div></span><div>I’m going to back Xiaodi on this one. The standard library is the standard for the language, by definition. That comes with some great things, and some concerning things.</div><div><br></div><div>If we decided anything that was generic and useful as a basis for programming got in, we wouldn’t call it the “Standard Library” - it would be the Kitchen Sink Library. It would be huge. The bar has to be set higher for the library.</div><div><br></div><div>Why is the current repeat functionality in there? Because Strings use it. Why is it public? Because, like you, people noticed it and said “That’s great generic functionality, why not expose it, and let everyone use it?” But that isn’t the bar for adding things: the bar is far higher for them to be added. Especially now as we’re trying to mature Swift from it’s immature fast-moving state. This may be the bar for *exposing* generic things, but the higher bar of “is this core?” may not be met with this proposal.</div><div><br></div><div>Don’t get me wrong, I think it’s a great idea. I just am not sure it meets the bar of “core”.</div></div></div></blockquote><div><br></div><div>Heck, it may even meet the bar for "core"! But not even core things all go into the standard library (for example, all of Foundation and Dispatch).</div><div><br></div><div>For instance, many people ask for additional math functionality here, and the repeated statement from the core team is that they'd like to see it as a third-party library, gain traction, then get nominated for inclusion as a core library. But even then, notice: core, not standard.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div class="h5"><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><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 dir="ltr"><div>Repeating a collection endlessly is a useful ability.</div></div></blockquote><div><br></div><div>I don't doubt it. Is your argument that any useful and commonly used feature should be part of the standard library? That's simply not the stated criteria for inclusion in the standard library. Hence, why Foundation exists outside of it. There's no point in debating these criteria, as (afaict) that's not up for debate. Again, I don't make the rules. I'm just saying they exist, and I'm arguing that we should abide by them.</div><div> </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 dir="ltr"><div>Yes, it can be written on top of the standard library. It would be generally nice not to require that *especially* when we can repeat single elements without similar effort. The asymmetry is awkward to remember for newbies and awkward to explain away with "we want a focused library so… the Thing A stays but this logically related Thing B can't be in even though showing you the ability to do A does tend to lead you to ask after Thing B."</div><div><div class="m_489130907280010425gmail-h5"><div><br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 1, 2017 at 11:55 PM, Xiaodi Wu <span dir="ltr"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></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">That's a tautological argument, though. By definition, if it's in the standard library, it becomes standardized and discoverable. This isn't at all a limiting principle for what goes into the library and what doesn't.<br><br>And as I said, there are many commonly useful facilities that aren't part of the standard library, by design and not by oversight. Left pad is one of them.<br><br>I'm trying to tease out whether this particular proposal meets the current bar for inclusion. If you believe left pad should be included, your beef is with the deliberate choice to have a small standard library, which as far as I know is not up for reconsideration.<div class="m_489130907280010425gmail-m_4026030989852958446gmail-HOEnZb"><div class="m_489130907280010425gmail-m_4026030989852958446gmail-h5"><br><div class="gmail_quote"><div dir="ltr">On Mon, May 1, 2017 at 22:41 T.J. Usiyan <<a href="mailto:griotspeak@gmail.com" target="_blank">griotspeak@gmail.com</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 dir="ltr">This gains discoverability and standardization by being part of the standard library. New folks would not have to import some library or roll their own to get this reasonable to expect/hope or hope for functionality. Perhaps removing the old function isn't going to work but repeating collections is definitely something useful.<div><br></div><div>Left padding for strings would be nice as well, but that is neither here nor there. </div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Mon, May 1, 2017 at 11:29 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></div></div><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"><span>On Mon, May 1, 2017 at 9:52 PM, Karl Wagner <span dir="ltr"><<a href="mailto:razielim@gmail.com" target="_blank">razielim@gmail.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span><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"><span class="m_489130907280010425gmail-m_4026030989852958446gmail-m_484438773169830509m_-1556577179268730800m_-3620511031778836470gmail-"><br>
> On 2 May 2017, at 04:44, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br>
><br>
> Does this gain something by being part of the standard library as opposed to being built on top of it?<br>
<br>
</span>Well, somebody thought repeatElement<T> was general enough to make part of the standard library. If we’re going to allow repeating a single item as a Collection, we might as well allow generalise it to repeating any Collection in a loop (including a CollectionOfOne, which is the existing use-case).<br></blockquote><div><br></div></span><div>That doesn't answer the question, though: does the feature you propose--repeating any instance of Collection in a loop--gain anything by being a part of the standard library rather than an extension to it?</div><div><br></div><div>There are _many_ useful algorithms that can be implemented on top of the standard library and can be of general use; nonetheless, they aren't a part of the standard library. IIUC, it's not because people just haven't had the time to flesh it out; rather, it is a deliberate choice to have a small, narrowly focused standard library. The philosophy, as I understand it, is to make it convenient for users to roll their own conveniences rather than providing all the bits and bobs in the library itself.</div><div><br></div><div>One of the points of differentiation between standard library and Foundation is said to be whether something is necessary to support a core language feature, in which case it goes into the standard library. As a consequence, there are less commonly used parts of the standard library which are there because they support other (decidedly not esoteric) parts of the standard library and also happen to have some plausible public uses. Taking a quick look into the repository, for instance, `repeatElement` is used in the implementation of `UnicodeScalar`. However, just because someone determined that `repeatElement` is worth making a public API (since it's going to be in the standard library whether or not it's public), doesn't _automatically_ mean that a generalization of it should be included in the library as well.</div><span><div><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">
Personally, I usually want to repeat a collection of things far more often than I want to repeat an individual thing. It annoys me that the standard library only provides the one I almost never need.<br></blockquote><div><br></div></span><div>There are many facilities that the standard library does not provide. Heck, we don't even have left padding for strings! (JavaScript reference, for those following along.) Is there something about this particular feature that makes its not being a part of the standard library uniquely problematic?</div><span><div><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">
Additionally, it could help remove the top-level “repeatElement” function, which I know irritates some people who would rather us not have any top-level functions in the standard library.<br></blockquote><div><br></div></span><div>With source stability as a goal, the bar for removal isn't "irritates some people." I actively use this function and there's no justification at all for breaking it. Frankly, I cannot see removal of top-level functions simply because they are top-level to be in scope essentially ever. So let's subset that out of this discussion.</div><div><br></div></div></div></div>
<br></blockquote></div></div><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">______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote></div></div></blockquote></div>
</div></div></blockquote></div><br></div></div></div></div></div></div>
</blockquote></div><br></div></div>
______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div></div></div><br></div></blockquote></div><br></div></div>