<div dir="ltr">+1 from me. I currently use reduce and just deal with the costs. </div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 14, 2017 at 10:15 PM, Matthew Johnson via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Apr 14, 2017, at 9:05 PM, David Sweeris <<a href="mailto:davesweeris@mac.com">davesweeris@mac.com</a>> wrote:<br>
><br>
><br>
>> On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>><br>
>>> • What is your evaluation of the proposal?<br>
>><br>
>> +0.5 because this is a half solution. I would also like to see a variant which accepts an inout argument for the reduction to accumulate into.<br>
><br>
> Out of curiosity, do you have any particular use case in mind, or do you just think that'd nicely "round out" the reduce functions (which would be fine with me).<br>
<br>
</span>This would be useful in any use case that involves reducing data that isn’t all available at the same time for one reason or another (batches arrive periodically, data is processed in chunks to avoid loading everything into memory, etc).<br>
<br>
IMO the most fundamental variation of `reduce` Swift could offer is the one that takes and `inout` accumulator. The others can easily be defined in terms of that.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> - Dave Sweeris<br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div>