> On Jan 22, 2017, at 10:56 PM, Chris Eidhof <[email protected]> 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 <[email protected]
> <mailto:[email protected]>> 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_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
