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

[Ben Cohen]

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.