[swift-evolution] Reduce with inout

[Chris Eidhof]

I've thought about it for a few days, and really like `reduce(mutating:_)`.
I've updated the PR, and am now happy for this to go into review.

https://github.com/apple/swift-evolution/pull/587

On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop <xenadu at gmail.com> wrote:

>
> On Jan 22, 2017, at 10:56 PM, Chris Eidhof <chris at eidhof.nl> wrote:
>
> Not as a direct reply to Russ, but just to reiterate: to me, there are two
> clear benefits of using the `inout` version of reduce:
>
> 1. The performance (currently discussed at length)
> 2. Readability (because we can use mutating methods on `inout` arguments).
>
> Even if the compiler were to optimize the unnecessary copy of `return arr
> + [el]` away, there are still a lot of other mutable methods that you might
> want to use within the reduce closure. So I think the proposal is still
> very valid even if the compiler optimizations would magically appear
> tomorrow.
>
> To push this proposal forward a little bit, I'd like to come up with a
> good name. It seems like we shouldn't overload `reduce`, but choose a
> different name, so that we don't stress the typechecker. Any other
> suggestions?
>
> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop <xenadu at gmail.com> wrote:
> --
> Chris Eidhof
>
>
>
> Sorry for the derail!
>
> reduce(mutating:_:) { } is still my favorite; You can take mutating to
> mean we will copy the value now but mutate it later.
>
>
> Some alternatives:
>
> reduce(forMutating:_:) { }
>
> reduce(forInout:_:) { }
>
> reduce(initial:_:) { }
>
> reduce(copying:mutate:) { }
>
> // just kidding...
> reduce(copyForLaterMutating:_:) { }
>
>
>
> It should definitely be some form of reduce.
>
> Russ
>



-- 
Chris Eidhof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170124/860f5057/attachment.html>