• 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.
Even if this would work I don’t think it’s a great option. Accepting an inout accumulator is a far more straightforward programming model with clear performance semantics that don’t require detailed implementation knowledge.
But that's not the only criterion. Is it as useful and commonly
convenient?
I would say it is commonly useful. When it is required it is as convenient as possible. When an inout accumulator is not required it is admittedly somewhat less convenient.
Whether it is *as* useful and convenient as the proposed variation probably depends on the domain. Each has their strength with the proposed version probably being a bit more frequently desired.
If we were to have both versions, how would you name them?
This is a tough question. The proposed `into:` label makes sense for both the inout accumulator and the proposed variation but I’ll assume overloading won’t be considered for the reasons stated in the proposal. `intoCopyOf:` would make sense for the proposed copying variation but would penalize it with verbosity and doesn’t copy reference types despite implying that.
The `mutating:` label described in the alternatives considered section of the proposal might might be the best option. One downside would be if the difference between `into:` and `mutating:` isn't sufficiently clear. Given that both the types *and* the labels distinct I think it’s probably ok. The second potential source of confusion would be if using `mutating:` as a label might cause some confusion with mutating methods. Again, a quick glance at the types reveals that the method is not mutating and the accumulator argument is taken as inout.
What is your thought on using the `into` for the proposed variation and `mutating` for the variation with an inout accumulator?
···
On Apr 16, 2017, at 12:47 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Fri Apr 14 2017, Matthew Johnson <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Apr 14, 2017, at 9:05 PM, David Sweeris <davesweeris@mac.com> wrote:
On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
--
-Dave
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution