<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I've thought about it for a few days, and really like `reduce(mutating:_)`. </div></div></blockquote><div><br></div><div>I'm not a fan of this. It reads in a way that makes it seem like the parameter should be inout, but it isn't. A variation of reduce where the initial value parameter *is* inout is perfectly sensible (whether or not we want it in the standard library). With that in mind, I don't think we should use this name. </div><div><br></div><div>Unfortunately I don't have a better suggestion. I think it was Brent who suggested "mutatingCopyOf" which is more accurate, but also undesirably verbose.</div><br><blockquote type="cite"><div><div dir="ltr">I've updated the PR, and am now happy for this to go into review.<div><br></div><div><a href="https://github.com/apple/swift-evolution/pull/587">https://github.com/apple/swift-evolution/pull/587</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop <span dir="ltr"><<a href="mailto:xenadu@gmail.com" target="_blank">xenadu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><span class=""><div>On Jan 22, 2017, at 10:56 PM, Chris Eidhof <<a href="mailto:chris@eidhof.nl" target="_blank">chris@eidhof.nl</a>> wrote:</div><br class="m_-7135271088127339095Apple-interchange-newline"></span><div><span class=""><div dir="ltr"><div>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:<br></div><div><br></div><div>1. The performance (currently discussed at length)</div><div>2. Readability (because we can use mutating methods on `inout` arguments).</div><div><br></div><div>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.</div><div><br></div><div>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?</div></div></span><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop <span dir="ltr"><<a href="mailto:xenadu@gmail.com" target="_blank">xenadu@gmail.com</a>></span> wrote:</div></span>-- <br><div class="m_-7135271088127339095gmail_signature" data-smartmail="gmail_signature">Chris Eidhof</div>
</div>
</div></blockquote></div><br><div><br></div><div>Sorry for the derail!</div><div><br></div><div>reduce(mutating:_:) { } is still my favorite; You can take mutating to mean we will copy the value now but mutate it later.</div><div><br></div><div><br></div><div>Some alternatives:</div><div><br></div><div>reduce(forMutating:_:) { }</div><div><br></div><div>reduce(forInout:_:) { }</div><div><br></div><div>reduce(initial:_:) { }</div><div><br></div><div>reduce(copying:mutate:) { }</div><div><br></div><div><div>// just kidding...</div><div>reduce(copyForLaterMutating:_:<wbr>) { }</div></div><div><br></div><div><br></div><div><br></div><div>It should definitely be some form of reduce. </div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Russ</div></font></span></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Chris Eidhof</div>
</div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>