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

[Nicolas Fezans]

On Tue, May 2, 2017 at 8:50 AM, David Hart via swift-evolution <
swift-evolution at swift.org> wrote:

> I'm not giving my opinion, but quoting Ben Cohen's great list of questions
> to ask ourselves before adding something to the Standard Library:
>
> All methods added to the standard library increase complexity, so need a
> strong justification to reduce the risk of API sprawl. When requesting
> additions/modifications, please keep the following questions in mind:
>
>    1. Is the suggested addition a common operation that many would find
>    useful? Can it be flexible enough to cover different needs?
>    2. Will it encourage good practice? Might it be misused or encourage
>    anti-patterns?
>    3. Can the operation be composed simply from existing std lib
>    features? Is that composition intuitive/readable?
>    4. Is writing the equivalent by hand hard to get right? Are there
>    common correctness traps that this addition would help avoid?
>    5. Is writing the equivalent by hand hard to make efficient? Are there
>    common performance traps that this addition would help avoid?
>
> I would advocate that point 5 can indeed be a bit hard (however I am not
sure that would justify the addition to the standard library). I often use
the functions "repmat" and "ndgrid" in MATLAB to prepare collections of
indexes to consider batch computations / combinatory problems. Due to the
limitation of the MATLAB language only indexes or parameters values are
usually contained in the repeated collections/matrices. As a consequence,
the object obtained through the repeatition usually remain manageable in
terms of memory.

If, however, people would like to do such things directly on some
collections of objects with resaonnable size, we might end up copying a lot
of data for nothing. It might also force programmers to modify their
classes / data structure to avoid this problem. As long as the "repeated"
data/collection is only used only for read operations (which I imagine to
be one of the main use cases with the for-in loops), copies could be
prevented.


>
>    1. Might a native implementation be able to execute more efficiently,
>    by accessing internals, than the equivalent implementation using public
>    APIs?
>
>
> On 2 May 2017, at 07:02, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Mon, May 1, 2017 at 9:34 PM, Karl Wagner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Currently, we have the Repeated<T> type, which presents a single element
>> as though it were a Collection.
>>
>> > for i in repeatElement(1, count: 3) { print(i) }
>> 1
>> 1
>> 1
>>
>> > for i in repeatElement([1, 2, 3], count: 3) { print(i) }
>> [1, 2, 3]
>> [1, 2, 3]
>> [1, 2, 3]
>>
>>
>> However, we lack the ability for Collections to repeat their contents in
>> a single list; basically, some kind of “flatMap” to repeatElement’s “map”.
>> So I’d like to pitch a new API for repeated values.
>>
>> - We would add a RepeatCollection<C: Collection> type, which loops over
>> its base Collection a certain number of times (or until a maximum ‘count’).
>>   Implementation might look something like this (
>> https://gist.github.com/karwa/5228974a0b4dfd000a916f0aac2721c6), except
>> that we’d add some optimised map(), filter() and contains() functions which
>> apply the algorithm once to the base and multiply the result.
>>
>> - We would add 3 new functions to all Collections:
>>
>> /// Repeats the collection *itself* N times.
>> ///
>> func repeated(_ times: Int) -> RepeatCollection<CollectionOfOne<Self>>
>>
>> /// Repeats the collection’s *contents* N times.
>> ///
>> func repeatElements(_ times: Int) -> RepeatCollection<Self>
>>
>> /// Loops the collection’s contents to present a Collection of length N.
>> ///
>> func repeatElements(count: Int) -> RepeatCollection<Self>
>>
>>
>> - We would replace the existing Repeated<T> type with a typealias to
>> RepeatCollection<CollectionOfOne<T>>
>> - The existing, top-level repeatElement(T, Int) function *could* stay,
>> but could also be replaced with an incantation on CollectionOfOne. I’m
>> fairly ambivalent about this point - it’d be nice to see the function go,
>> but the replacement also isn’t obvious.
>>
>> Example usage of the new API:
>>
>> // Equivalent to repeatElement(1, count: 3)
>>
>> > for i in CollectionOfOne(1).repeatElements(3).forEach { print(i) }
>> 1
>> 1
>> 1
>>
>> // Equivalent to repeatElement([1, 2, 3], count: 3)
>>
>> > for i in [1, 2, 3].repeated(3).forEach { print(i) }
>> [1, 2, 3]
>> [1, 2, 3]
>> [1, 2, 3]
>>
>> // New, flat repetition
>>
>> > for i in [1, 2, 3].repeatElements(3) { print(i) }
>> 1
>> 2
>> 3
>> 1
>> 2
>> 3
>> 1
>> 2
>> 3
>>
>> // New, flat repetition
>>
>> > for i in [1, 2, 3].repeatElements(count: 4) { print(i) }
>> 1
>> 2
>> 3
>> 1
>>
>> // Additional benefit: you can now repeat slices!
>>
>> > String(“yellow”.characters.dropFirst().dropLast().repeat(times: 3))
>> “elloelloello"
>>
>>
>> Thoughts?
>>
>
> OK, now as to your proposed APIs themselves, here are some critiques:
>
> The issue you've identified with the cumbersome nature of CollectionOfOne
> shows why repeatElement is currently a top-level function and intentionally
> so. In brief, there's nothing special about Collection to make it the
> obvious type on which to provide a `repeated` method. The _result_ of that
> operation is a collection, but there's no reason the argument has to be.
> The correct "type" on which to provide that method would be Any, IMO, but
> of course we cannot provide extensions on Any. In general, in such
> scenarios, the consistent design choice in the standard library is to
> provide a free function.
>
> Here, it is not inconsistent to _add_ something for repeating the elements
> in a collection (to Collection itself) without also stuffing the existing
> `repeatElement` functionality into Collection. TBH, the latter seems like
> an orthogonal topic included for the express purpose of eliminating
> top-level functions, without addressing the underlying reason for the
> existence of these top-level functions in the first place (no extensions on
> Any). So again, unrelated and worth setting aside, IMO.
>
> Other minor points include that `repeatElements` doesn't meet standard API
> naming guidelines. It should be `repeatingElements`. You also intuitively
> tacked on a `times` argument label in the example usage even though your
> proposed API doesn't have it. It suggests that `repeat[ing]Elements(3)` is
> actually quite ambiguous: repeat the value 3, repeat the whole collection 3
> times, or repeat so that the final count is 3? Better to have the label
> always, I should think. Another point is that it'd take some justification
> to include both flavors of `repeat[ing]Elements`, as repeating until a
> final count is trivially composed with new one-sided ranges: `[1, 2,
> 3].repeatingElements(times: .max)[..<4]`.
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/1c343795/attachment.html>