[swift-evolution] Reduce with inout
Pranshu Goyal
pranshu.goyal at novanet.net
Wed Jan 18 00:30:42 CST 2017
What about `reducing(x, combine: {...})`
On 18 January 2017 at 07:47, Xiaodi Wu via swift-evolution <
swift-evolution at swift.org> wrote:
> 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`.
>
>
> On Tue, Jan 17, 2017 at 7:46 PM, Sean Heber <sean at fifthace.com> wrote:
>
>> `reuse`
>>
>> Then we just need an excuse for a function named ‘recycle’...
>>
>> l8r
>> Sean
>>
>>
>> > On Jan 17, 2017, at 7:36 PM, T.J. Usiyan via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >
>> > `reduceInout`
>> >
>> > On Tue, Jan 17, 2017 at 6:30 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> > Agree. The functional style should keep the functional name.
>> >
>> > On Tue, Jan 17, 2017 at 16:18 David Sweeris via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >
>> > On Jan 17, 2017, at 16:11, Karl Wagner via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >
>> >>
>> >>> On 17 Jan 2017, at 23:09, Karl Wagner <karl.swift at springsup.com>
>> wrote:
>> >>>
>> >>>
>> >>>> On 16 Jan 2017, at 14:49, Chris Eidhof via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> How does everyone feel about adding a second version of `reduce` to
>> `Sequence`? Instead of a `combine` function that's of type `(A, Element) ->
>> A`, it would be `(inout A, Element) -> ()`. This way, we can write nice
>> functionals algorithms, but have the benefits of inout (mutation within the
>> function, and hopefully some copy eliminations).
>> >>>>
>> >>>> IIRC, Loïc Lecrenier first asked this on Twitter. I've been using it
>> ever since, because it can really improve readability (the possible
>> performance gain is nice, too).
>> >>>>
>> >>>> Here's `reduce` with an `inout` parameter, including a sample:
>> https://gist.github.com/chriseidhof/fd3e9aa621569752d1b04230f92969d7
>> >>>>
>> >>>> --
>> >>>> Chris Eidhof
>> >>>> _______________________________________________
>> >>>> swift-evolution mailing list
>> >>>> swift-evolution at swift.org
>> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >>>
>> >>> +1
>> >>>
>> >>> I would even argue for it to be the default.
>> >>
>> >> I mean, assuming having two “reduce”s would stress the typechecker, as
>> Joe suggested it might, I would say “inout” makes sense to be the default
>> and the other one can find itself a new name.
>> >
>> > IIRC, the "reduce" name comes from functional programming... should the
>> functional style keep the functional name?
>> >
>> > - Dave Sweeris
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> >
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> >
>> >
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
--
*Pranshu Goyal*
*iOS Developer*
*tlkn*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170118/0af83a37/attachment.html>
More information about the swift-evolution
mailing list