Er… sorry, by “returns results” I mean, return the removed items. Thanks, Jon
> On Sep 26, 2017, at 4:59 PM, Jonathan Hull <jh...@gbis.com> wrote: > > The main issue here is that the proposal is missing the variant which returns > the elements that are removed… and that throws out a lot of very useful use > cases. > >> 1. Is it right to assert that with a “removing” operation, the closure >> should return `true` for removal? > Yes > >> 2. Is it likely that users will want to switch from out-of- to in-place, and >> if so, will having to flip the closure cause confusion/bugs? > They always have the option of just inverting the closure. I doubt people > will change the function being used unless they are doing a larger refactor > (or need the removed results). > >> 3. Should we “complete” the matrix of 4 operations, or is it fine for it to >> have gaps? > I am on the fence. I don’t think gaps will cause an issue, but I could see > the usefulness of having more options (but are they worth the upkeep?). > >> 4. If you are for completing, what should X and Y be called? > removing(where:) and formFilter() (though I have always been a fan of > filter/filtered) > > > As I mentioned above, I think that either returning @discardableResults or > having a variant which returns the results is very important. Look at the > other thread on this topic from this morning for a discussion of why. > > Thanks, > Jon > > >> On Sep 26, 2017, at 4:12 PM, Ben Cohen via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> Hi everyone, >> >> Reviving a pitch for a feature that didn’t make it into Swift 4. This was >> discussed in the core team recently, and feedback was wanted regarding the >> naming of the method and the polarity of the where closure. >> >> Here’s the proposal: >> >> https://github.com/airspeedswift/swift-evolution/blob/0f4a24d6ded2ab7cb39c1a68e0f92705a7615d73/proposals/NNNN-RemoveWhere.md >> >> To keep things simple, this version removes the Equatable version. That >> could be added as a separate proposal. >> >> >> The issue to resolve is: should the closure have the same polarity as >> filter, and if not, should filter also have an in-place equivalent? >> (wait, don’t reply yet, read the rest of the email first :) >> >> From the original proposal: >> >>> `remove(where:)` takes a closure with `true` for elements to remove. >>> `filter` takes a closure with `true` for elements to keep. In both cases, >>> `true` is the "active" case, so likely to be what the user wants without >>> having to apply a negation. The naming of `filter` is unfortunately >>> ambiguous as to whether it’s a removing or keeping operation, but >>> re-considering that is outside the scope of this proposal. >> >> >> Assuming you accept the premise that a closure returning `true` to `remove` >> is the “right way around” for the argument to an in-place removal operation, >> this means that we have a situation where if you want to flip from in-place >> to out-of-place removal, you have to reverse the closure. >> >> Alternatively, we could duplicate the functionality, and have both filter >> and remove operations have in- and out-of-place variants, completing this >> 2x2 matrix: >> >> out-of-place, true to keep: filter(_:) >> in-place, true to remove: remove(where:) >> out-of-place, true to remove: X? >> in-place, true to keep: Y? >> >> The names for X that fall easily out of the naming guidelines are >> removed(where:) or removing(where:) >> >> Y is trickier. Normally, the out-of-place would be a variant (like the past >> participle) of the mutating operation, but with filter the out-of-place >> method is already named,* so options are limited. formFilter(_:) is one >> suggestion. >> >> >> To help guide feedback on this, here are 4 questions to answer: >> >> 1. Is it right to assert that with a “removing” operation, the closure >> should return `true` for removal? >> 2. Is it likely that users will want to switch from out-of- to in-place, and >> if so, will having to flip the closure cause confusion/bugs? >> 3. Should we “complete” the matrix of 4 operations, or is it fine for it to >> have gaps? >> 4. If you are for completing, what should X and Y be called? >> >> Any answers, or further thoughts on any of the above, appreciated. >> >> Ben >> >> >> >> * while you could argue that this can be resolved by renaming filter, >> renames like this have a very high bar to clear. Also, filter is a term of >> art, hence its previous exemption from the naming guidelines. >> >> >> _______________________________________________ >> 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
