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

[T.J. Usiyan]

Xi: "Does this gain something by being part of the standard library?"
Me: "This gains discoverability and standardization by being part of the
standard library."
Xi: "By definition, if it's in the standard library, it becomes
standardized and discoverable."

We're in agreement, then?

Repeating a collection endlessly is a useful ability. 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."


On Mon, May 1, 2017 at 11:55 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> 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.
>
> 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.
>
> 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.
>
> On Mon, May 1, 2017 at 22:41 T.J. Usiyan <griotspeak at gmail.com> wrote:
>
>> 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.
>>
>> Left padding for strings would be nice as well, but that is neither here
>> nor there.
>>
>> On Mon, May 1, 2017 at 11:29 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> 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.
>>>
>>>
>>> _______________________________________________
>>> 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/20170502/b32c0d19/attachment.html>