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
