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.

-- 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 <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