What is your evaluation of the proposal?
+1 for the functionality.
I agree with Nate’s argument for naming it
I’m also bugged by the inconsistency that’s bugging Erica;
filterInPlace would also make sense (with the condition swapped, obviously). However, John’s reply makes sense to me.
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
It’s an obvious and annoying oversight in the stdlib that I’ve repeatedly had to implement myself, probably ineffeciently.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Ruby provides a method quartet (mutating / non-moutating; true keeps / true removes) for this:
(The exclamation point in Ruby is part of the method name, and by convention indicates mutation or other “dangerous” methods.)
It’s surprisingly helpful for code readability to have both
reject in the toolbox. It allows concise method refs where a closure would otherwise be required, and more importantly the name difference is often more conspicuous than the not operator. They help code read better. (I like to alias
all for similar reasons.)
However, given Swift’s precedent of using
filter, I don’t see a similar name quartet that reads as nicely. In a green field, I might propose this Swifty parallel to Ruby:
…but this is a far departure, and I don’t think it warrants a change to the library. The duo (not quartet) named as proposed seems good enough to me, if not ideal.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?