[swift-evolution] Reduce with inout

[Chris Eidhof]

But if we want to add "copyOf" we should do that to every method that takes
a struct? Also, what if you pass in an object?

I see the concern, but I don't think adding `copyOf` will increase clarity.
That said, I'm open to suggestions.

On Tue, Jan 24, 2017 at 2:43 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> It's only verbose if the words aren't needed! The shortest way to describe
> something with sufficient accuracy can never be verbose, let alone
> undesirable, and I highly agree with this concern. We already have names of
> this form, such as `FloatingPoint.init(signOf:magnitudeOf:)`.
>
> On Tue, Jan 24, 2017 at 07:33 Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>>
>> Sent from my iPad
>>
>> On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> I've thought about it for a few days, and really like
>> `reduce(mutating:_)`.
>>
>>
>> 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.
>>
>> Unfortunately I don't have a better suggestion.  I think it was Brent who
>> suggested "mutatingCopyOf" which is more accurate, but also undesirably
>> verbose.
>>
>> I've updated the PR, and am now happy for this to go into review.
>>
>> https://github.com/apple/swift-evolution/pull/587
>>
>> On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop <xenadu at gmail.com> wrote:
>>
>>
>> On Jan 22, 2017, at 10:56 PM, Chris Eidhof <chris at eidhof.nl> wrote:
>>
>> 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:
>>
>> 1. The performance (currently discussed at length)
>> 2. Readability (because we can use mutating methods on `inout` arguments).
>>
>> 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.
>>
>> 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?
>>
>> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop <xenadu at gmail.com> wrote:
>> --
>> Chris Eidhof
>>
>>
>>
>> Sorry for the derail!
>>
>> reduce(mutating:_:) { } is still my favorite; You can take mutating to
>> mean we will copy the value now but mutate it later.
>>
>>
>> Some alternatives:
>>
>> reduce(forMutating:_:) { }
>>
>> reduce(forInout:_:) { }
>>
>> reduce(initial:_:) { }
>>
>> reduce(copying:mutate:) { }
>>
>> // just kidding...
>> reduce(copyForLaterMutating:_:) { }
>>
>>
>>
>> It should definitely be some form of reduce.
>>
>> Russ
>>
>>
>>
>>
>> --
>> Chris Eidhof
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>


-- 
Chris Eidhof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170124/2cb8dd08/attachment.html>