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() }

> On Aug 17, 2017, at 9:06 PM, Erica Sadun via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
>> On Aug 17, 2017, at 6:56 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>> 
>>> On Thu, Aug 17, 2017 at 7:51 PM, Erica Sadun <er...@ericasadun.com> wrote:
>>> 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.
>> 
>> 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?
>> 
>> ```
>> repeatElement((), count: 5).map { UIView() }
>> ```
> 
> 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.
> 
> 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.
> 
> -- E
> 
>>>> On Aug 17, 2017, at 3:53 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>>> 
>>>> 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.
>>>> 
>>>> 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 }”.
>>>> 
>>>> On Thu, Aug 17, 2017 at 16:01 Erica Sadun via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>>>> On Aug 17, 2017, at 12:04 PM, Max Moiseev <mois...@apple.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> On Aug 17, 2017, at 10:05 AM, Erica Sadun via swift-evolution 
>>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>> 
>>>>>>> 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)
>>>>>> 
>>>>>> Can you please elaborate why (or maybe point me at the rant)? 
>>>>> 
>>>>> 
>>>>> Summary:
>>>>> 
>>>>> . 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
>>>>> 
>>>>> -- E
>>>>> 
>>>>> _______________________________________________
>>>>> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to