[swift-evolution] [Pitch] New collection-based 'repeat' API

[Xiaodi Wu]

On Mon, May 1, 2017 at 9:52 PM, Karl Wagner <razielim at gmail.com> wrote:

>
> > On 2 May 2017, at 04:44, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> >
> > Does this gain something by being part of the standard library as
> opposed to being built on top of it?
>
> 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).
>

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?

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.

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.

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

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?

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170501/c9b25ebc/attachment.html>