> 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 
> <mailto: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 
>> <mailto: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 <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> On Aug 17, 2017, at 12:04 PM, Max Moiseev <mois...@apple.com 
>>> <mailto:mois...@apple.com>> wrote:
>>> 
>>> 
>>>> On Aug 17, 2017, at 10:05 AM, Erica Sadun via swift-evolution 
>>>> <swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <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