[swift-evolution] [Pitch] Improve `init(repeating:count)`

[Xiaodi Wu]

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 at swift.org> wrote:

>
> On Aug 17, 2017, at 12:04 PM, Max Moiseev <moiseev at apple.com> wrote:
>
>
> On Aug 17, 2017, at 10:05 AM, Erica Sadun via swift-evolution <
> swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170817/4c804ee1/attachment.html>