<div dir="ltr">On Mon, May 1, 2017 at 11:15 PM, Xiaodi Wu <span dir="ltr"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.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 dir="ltr"><span class="">On Mon, May 1, 2017 at 10: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 class=""><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 class="m_4479343531674162701gmail-"><blockquote type="cite"><div>On 2 May 2017, at 05:29, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_4479343531674162701gmail-m_-3517345633522054011Apple-interchange-newline"><div><div dir="ltr">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><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"><span class="m_4479343531674162701gmail-m_-3517345633522054011gmail-"><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><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></div></div></div></div></blockquote><div><br></div></span><div>This seems contradictory. Either the standard library is small and deliberately focussed; or it isn’t and it’s okay for random "bits and bobs” such as repeatElement to be public just because the standard library arbitrarily uses them somewhere.</div></div></div></blockquote><div><br></div></span><div>I don't see how. The standard library _is_ small--and it's focused, though not perhaps on what you think it should be. It's not that only the most commonly sought-after features go into the standard library; it's that only such features as are necessary to support the core language go into the standard library. `repeatElement` isn't randomly part of the library; it's used to implement strings.</div><span class=""><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 style="word-wrap:break-word"><div><div>Either “repeat” functionality (in general) is useful and the generalised behaviour should be in the standard library, or none of it should be. </div></div></div></blockquote><div><br></div></span><div>That doesn't follow at all. It's like saying, either types (in general) are useful and higher-kinded types should be supported by Swift, or Swift should be untyped.</div><span class=""><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 style="word-wrap:break-word"><div><span class="m_4479343531674162701gmail-"><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">
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><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></div></div></div></div></blockquote><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">
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><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.</div></div></div></div></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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>
</div></blockquote></span></div><div><br></div><div>Again, this seems contradictory given your comments just a few lines up about how spartan the stdlib is supposed to be. Why do you insist that this single-purpose function remain,</div></div></blockquote><div><br></div></span><div>*I'm* not inventing the source stability criteria here. It's been made very clear that the bar for removing something existing the language now is very high and not at all based on whether it would be included in the first place if it were proposed today. There have been several criteria laid out for such source-breaking changes, and "irritates some people" doesn't meet that bar. In insisting on preserving source stability, I'm only insisting that we respect the process laid out for Swift evolution, because that's the only way this thing can work. Again, I don't come up with the criteria, but we shouldn't need to litigate the ground rules every time an idea is discussed.</div></div></div></div></blockquote><div><br></div><div>I should add, I have always personally been sympathetic towards the idea that free functions are less discoverable than methods, and that the standard library is better off with fewer of them. Back in the Swift 3 days, I was definitely in support of removing a number of these, such as `max` and `min`. I believe you and I were part of such a conversation back then. But I think it's important to play by the rules, so to speak, and source stability is here and clearly being prioritized. I believe very strongly that this process only works when we respect and work together to promote the identified priorities, not poke holes against them.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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 style="word-wrap:break-word"><div>and the more broadly-useful, generalised functionality cannot possibly be a fit for the standard library?</div></div></blockquote><div><br></div></span><div>I think, if you read back, I have never insisted that your proposed functionality is not a fit. I simply asked you a question: does this generalized feature fit the existing, stated focus that the standard library doesn't vend every useful function, but only those necessary for supporting the core language? It appears that _you're_ saying it doesn't, but that you also don't agree with those criteria. Again, I don't come up with the criteria. I'm just bringing up that they exist.</div><span class=""><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 style="word-wrap:break-word"><div>It seems that the reverse is more likely to be true.</div><div><br></div><div>As I said, I personally don’t care about what happens to the top-level function. This is only a pitch, so I wanted to hear from those people who really do want to remove them all before writing up a full proposal.</div></div></blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>