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 < [email protected]> wrote: > > On 18 Jan 2017, at 09:00, Anton Zhilin via swift-evolution < > [email protected]> 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 < > [email protected]>: > >> 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 > [email protected] > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > -- Chris Eidhof
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
