<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 17, 2017, at 9:29 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" class="">kelvin13ma@gmail.com</a>> wrote:</div><div class=""><div class="gmail_extra" style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="gmail_quote">On Thu, Aug 17, 2017 at 9:06 PM, Erica Sadun via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><br class=""><div class=""><span class="gmail-"><blockquote type="cite" class=""><div class="">On Aug 17, 2017, at 6:56 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="gmail-m_-4653050338675132092Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Thu, Aug 17, 2017 at 7:51 PM, Erica Sadun<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:erica@ericasadun.com" target="_blank" class="">erica@ericasadun.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-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></span>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><span class="gmail-"><div class=""><br class=""></div><div class="">-- E</div></span><br class=""></div></blockquote></div><br class=""></div><div class="gmail_extra" style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">To me at least, this is a very i-Centric complaint, since I can barely remember the last time I needed something like this for anything that didn’t involve UIKit. What you’re asking for is API sugar for generating reference types with less typing. </div></div></blockquote><br class=""></div><div>No, that's what the original thread poster wanted.</div><div><br class=""></div><div>I want to avoid breaking math. For any x passed to a function, I expect f(x) to produce the same result. To map is to create a relation so that for every x in a domain, there is a single y that it produces. You can hand-wave and say the map is "producing" the closure, but it's not. It's executing it and recovering a value.</div><div><br class=""></div><div>How we get past the `(n ... m).map({ _ in ... })` pattern may be through language guidance or through language evolution. Either way, it doesn't make this pattern not problematic and worthy of discussion.</div><div><br class=""></div><div>Finally, I don't think Swift Evolution _can_ be considered entirely outside the auspices of the Apple halo. Look at SE-0005, SE-0006, and SE-0023 for example. i-Centricity is inescapable given the core team and the hosting domain for this project.</div><div><br class=""></div><div>-- E</div><div><br class=""></div></body></html>