[swift-evolution] Reduce with inout

Xiaodi Wu xiaodi.wu at gmail.com
Wed Jan 18 06:26:45 CST 2017


Thought: if the idea is performance and not drop-in replacement, why force
the user to incur two copies? If the initial value were inout, this
function would be more unambiguous even without a new name, and at _worst_
the user has to declare a variable with var, a worthwhile trade-off to save
two copies.

(Ack, Jeremy just beat me to it!)
On Wed, Jan 18, 2017 at 05:45 Chris Eidhof via swift-evolution <
swift-evolution at swift.org> wrote:

> I opened up a WIP PR on the SE repository (so many TLA's!).
> https://github.com/apple/swift-evolution/pull/587
>
> I think I'll wait a few days before removing `WIP` until the naming
> discussion either reaches consensus or settles down.
>
> So far, I would summarize the thread as: people are in favor, but there is
> disagreement on the naming. I suspect the core team will ultimately decide
> on the naming?
>
> On Wed, Jan 18, 2017 at 11:11 AM, Chris Eidhof <chris at eidhof.nl> wrote:
>
> I don't think we should replace the current `reduce` with the `inout`
> version, also because the current reduce can be really useful as well (e.g.
> when the return type is an Int).
>
> One downside of having a different name is that it'll be harder to
> discover this version. If stressing the type-checker is the only problem,
> then maybe we should improve the type-checker, instead of placing that
> burden on every user of the language.
>
>
>
> On Wed, Jan 18, 2017 at 9:36 AM, Karl Wagner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On 18 Jan 2017, at 09:00, Anton Zhilin via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> While realizing that this name can cause confusion, I'd still prefer
> `reduce(mutating:_:)`, because it looks like the only readable option to me.
> Whatever name will be picked, I agree that traditional reduce without
> mutation should retain its name.
>
> 2017-01-18 5:17 GMT+03:00 Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org>:
>
> A serious possibility would be: `reduce(mutableCopyOf: x) { ... }`.
>
> It's verbose, but the nicer-looking `reduce(mutating: x) { ... }` is
> incorrect since, as Charles pointed out to Dave, it's not `x` that's
> mutated but rather a mutable copy of it, so it doesn't matter if `x` itself
> is declared with `let` or `var`.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> I suppose as a second-choice I’d go for accumulate(into: with:):
>
> [1, 2, 3].accumulate(into: 0, with: +=)
>
> even [1, 2, 3].accumulate(into: 0, with: -=) doesn’t look so bad IMO.
>
> - Karl
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> --
> Chris Eidhof
>
>
>
>
> --
> Chris Eidhof
> _______________________________________________
> 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/20170118/d4e43773/attachment.html>


More information about the swift-evolution mailing list