[swift-evolution] Re-pitch: remove(where:)
Ben Cohen
ben_cohen at apple.com
Tue Sep 26 18:14:53 CDT 2017
And here are my answers, in a separate email to maintain a shred of separation between objectivity and subjectivity :)
> On Sep 26, 2017, at 4:12 PM, Ben Cohen via swift-evolution <swift-evolution at swift.org> wrote:
>
> 1. Is it right to assert that with a “removing” operation, the closure should return `true` for removal?
Yes. If the closure returned false for removal a different, less readable, name would be needed for the method.
> 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?
I don’t think so. While the argument for an in-place remove is partly that it’s more efficient than x = x.filter (in addition to reability/discoverability benefits), I think that once both an in- and out-of-place version are available, users will reach immediately for the one they want. The scenario where you were filtering, and then you realize you could do it in-place more efficiently, doesn’t seem to me like it will come up in day-to-day use.
> 3. Should we “complete” the matrix of 4 operations, or is it fine for it to have gaps?
I think filter(_:) and remove(where:) are sufficient. I don’t think we need to complete the set.
> 4. If you are for completing, what should X and Y be called?
>
One of the reasons I _don’t_ think we should complete the set is that formFilter(_:) will take us into serious jumped-the-shark territory, naming-wise.
I think there’s an argument for never having had filter, and always having had remove/removed (or possibly select/selected), but don’t think this is important enough to clear the bar for a rename of this magnitude.
More information about the swift-evolution
mailing list