<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">`repeatElement((), count: 5)` is better than `1 ... 5`, but `Count(3).map({ UIView() })` is far more elegant. I'd still probably go with an array initializer or `5.elements(of: UIView())`. I don't think I'm overstating how common this pattern is, and `Array(repeating:count:)` feels _close_ but not close enough.</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Aug 17, 2017, at 7:13 PM, Robert Bennett <<a href="mailto:rltbennett@icloud.com" class="">rltbennett@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""></div><div class="">Xiaodi, you pretty much took the words out of my mouth. I was going to suggest a Count collection whose Element was Void and with the sole initializer init(_ count: Int). The type would just contain its count and pretty much fake its collection interface, in the sense that no elements are actually stored. Then you could do Count(3).map { UIView() }</div><div class=""><br class="">On Aug 17, 2017, at 9:06 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 17, 2017, at 6:56 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Thu, Aug 17, 2017 at 7:51 PM, Erica Sadun <span dir="ltr" class=""><<a href="mailto:erica@ericasadun.com" target="_blank" class="">erica@ericasadun.com</a>></span> wrote:<br class=""><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 style="word-wrap:break-word" class=""><div class="">What people are doing is taking a real set of values (1, 2, 3, 4, 5, for example), then discarding them via `_ in`, which is different from `Void -> T` or `f(x) = 0 * x`. The domain could just as easily be (Foo(), "b", 💩, UIColor.red, { x: Int in x^x }). There are too many semantic shifts away from "I would like to collect the execution of this closure n times" for it to sit comfortably.</div></div></blockquote><div class=""><br class=""></div><div class="">What arguments might help to alleviate this discomfort? Clearly, functions exist that can map this delightfully heterogeneous domain to some sort of range that the user wants. Would you feel better if we wrote instead the following?</div><div class=""><br class=""></div><div class="">```</div><div class="">repeatElement((), count: 5).map { UIView() }</div><div class="">```</div></div></div></div></div></blockquote><div class=""><br class=""></div>My favorite solution is the array initializer. Something along the lines of `Array<T>(count n: Int, generator: () -> T)`. I'm not sure it _quite_ reaches standard library but I think it is a solid way to say "produce a collection with a generator run n times". It's a common task. I was asking around about this, and found that a lot of us who work with both macOS and iOS and want to stress test interfaces do this very often. Other use cases include "give me n random numbers", "give me n records from this database", etc. along similar lines.</div><div class=""><br class=""></div><div class="">The difference between this and the current `Array(repeating:count:)` initializer is switching the arguments and using a trailing closure (or an autoclosure) rather than a set value. That API was designed without the possibility that you might want to repeat a generator, so there's a bit of linguistic turbulence.</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><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 style="word-wrap:break-word" class=""><div class=""><div class="h5"><div class=""><blockquote type="cite" class=""><div class="">On Aug 17, 2017, at 3:53 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_8972578855228478123Apple-interchange-newline"><div class="">This is, I would argue, much too limiting in the way of semantics and not at all required by “map”. It’s unclear to me how _any_ result with reference semantics or any function with side effects could be used in a way that comports with that definition.<br class=""><br class="">On the other hand, just as y = 0x is a function, { _ in Foo() } is a closure that very much does project from a domain to a range. I’m not sure I understand what wins are to be had by having “collect {}” as a synonym for “map { _ in }”.<br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Aug 17, 2017 at 16:01 Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On Aug 17, 2017, at 12:04 PM, Max Moiseev <<a href="mailto:moiseev@apple.com" target="_blank" class="">moiseev@apple.com</a>> wrote:</div><br class="m_8972578855228478123m_3317284721246939440Apple-interchange-newline"><div class=""><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 17, 2017, at 10:05 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_8972578855228478123m_3317284721246939440Apple-interchange-newline"><div class=""><div style="word-wrap:break-word" class=""><div class="">Also, for those of you here who haven't heard my previous rant on the subject, I dislike using map for generating values that don't depend on transforming a domain to a range. (It has been argued that `_ in` is mapping from `Void`, but I still dislike it immensely)</div></div></div></blockquote><div class=""><br class=""></div><div class="">Can you please elaborate why (or maybe point me at the rant)? </div></div></div></div></blockquote></div><br class=""><div class=""><br class=""></div></div><div style="word-wrap:break-word" class=""><div class="">Summary:</div><div class=""><br class=""></div><div class="">. Since this application is a generator and not a transformative function, `map` is a misfit to usage semantics. It breaks the contract that map means to project from a domain to a range via a function. More languages conventionally use `collect` than `map` to collect n applications of a generator closure</div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div></div>______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div>
</blockquote></div><br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></body></html>