> https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md > > • What is your evaluation of the proposal?
I support this proposal. It is easy to inadvertently write inefficient algorithms with reduce, and this provides a built-in solution. The parameter label is decent, and it differentiates the overloads nicely; that helps with readability. I think that the straight overload case becomes less readable; that happens to reinforce the compiler performance concern. > • Is the problem being addressed significant enough to warrant a change to > Swift? Yes. A lot of transformations can be implemented on top of ‘reduce’; this will help a class of those solutions be more efficient. > • Does this proposal fit well with the feel and direction of Swift? Yes. A functional algorithm that embraces mutation in the name of efficiency: so swifty. > • How much effort did you put into your review? A glance, a quick reading, or > an in-depth study? Participated in discussion, experimented with the concept. Guillaume Lessard _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
