[swift-evolution] SE-0171: Reduce with inout

Dave Abrahams dabrahams at apple.com
Sun Apr 16 00:47:06 CDT 2017


on Fri Apr 14 2017, Matthew Johnson <swift-evolution at swift.org> wrote:

>> On Apr 14, 2017, at 9:05 PM, David Sweeris <davesweeris at mac.com> wrote:
>> 
>> 
>>> On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>>>   • What is your evaluation of the proposal?
>>> 
>>> +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.
>> 
>> 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).
>
> 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).
>
> 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.

It should work to do this:

  existingAccumulator = reduce(into: existingAccumulator) { ... }

If reduce is inlined, ARC is doing its job right, and the closure isn't
throwing, it shouldn't even cost a copy of existingAccumulator.

If you have a heaviweight accumulator with value semantics and ARC
isn't cutting it for you, you can do this ugly thing instead.

  extension Optional {
    mutating func release() -> Wrapped {
      defer { self = nil }
      return self!
    }
  }

  var accumulator: AccumulatorType? = AccumulatorType()
  accumulator = reduce(into: accumulator.release()) { ... }

but then you lose the accumulator if the closure throws.  So, I guess
I'm agreeing with you that the version with the inout accumulator is
more fundamental.

But that's not the only criterion.  Is it as useful and commonly
convenient?  If we were to have both versions, how would you name them?

-- 
-Dave



More information about the swift-evolution mailing list