[swift-evolution] Reduce with inout

[Russ Bishop]

> 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 <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170122/6bf8b7a7/attachment.html>