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...@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 <griotsp...@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@swift.org> wrote: >> >>> On Mon, May 1, 2017 at 9:52 PM, Karl Wagner <razie...@gmail.com> wrote: >>> >>>> >>>> > On 2 May 2017, at 04:44, Xiaodi Wu <xiaodi...@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@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution