[swift-evolution] Re-pitch: remove(where:)

[Jonathan Hull]

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution