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 <[email protected]> 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 < > [email protected]> wrote: > >> >> >> Sent from my iPad >> >> On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution < >> [email protected]> 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 <[email protected]> wrote: >> >> >> On Jan 22, 2017, at 10:56 PM, Chris Eidhof <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > -- Chris Eidhof
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
