Yes, Matthew, I agree with you exactly on this. It's tricky. `copyOf` isn't ideal at all, but `mutating` is potentially misleading. Ah the difficulties of naming things.
On Tue, Jan 24, 2017 at 09:15 Matthew Johnson <matt...@anandabits.com> wrote: > On Jan 24, 2017, at 8:12 AM, Chris Eidhof <ch...@eidhof.nl> wrote: > > 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. > > > I’m not really trying to advocate for “copyOf”. I think we should really > have something more concise in a case like this. My main point is that > just using `mutating` is inaccurate and therefore probably not the right > solution. > > Your question about passing in an object (I assume you mean a reference > type here) is a good one. In an ideal world that would probably not be > allowed as it doesn’t really make sense to replace the reference during > reduction. Unfortunately I don’t think we have a way to prevent that at > the moment. > > > On Tue, Jan 24, 2017 at 2:43 PM, Xiaodi Wu <xiaodi...@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:)`. > > > I mostly agree with this Xiaodi, but I also think that commonly known and > frequently used methods like `reduce` deserve to be as concise as > possible. That is less a concern with less common and less frequently used > signatures. > > > On Tue, Jan 24, 2017 at 07:33 Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Sent from my iPad > > On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution < > swift-evolution@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 <xen...@gmail.com> wrote: > > > On Jan 22, 2017, at 10:56 PM, Chris Eidhof <ch...@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 <xen...@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > -- > Chris Eidhof > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution