[swift-evolution] [pitch] Adding in-place removeAll to the std lib

David Hart david at hartbit.com
Mon Apr 10 00:03:57 CDT 2017



> On 10 Apr 2017, at 04:46, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Well, if we're going to bikeshed:
> 
> I think removeAll(3) reads fine, while removeAll(of: 3) does not. I do not think that reads right at all--what is "all of three"? Do we mean to contrast it to "some of three"--like, maybe, two of three?
> 
> By comparison, index(of: 3) works because the element equal to three has a corresponding index. However, neither the element equal to three, nor three itself, has a corresponding "allness."
> 
> Put another way, "of" is not a preposition that can substitute for "equal to." This becomes obvious if you consider that, while removeAll(equalTo:) makes perfect sense, index(equalTo:) is not an appropriate alternative (aesthetically pleasing or not) name for index(of:). If verbosity were not an issue, the full names might be:
> 
> removeAllElements(equalTo:)
> index(ofFirstElementEqualTo:)
> 
> From these hypothetical forms (I'm not suggesting we rename!), one can see how "of" does not really fit with the sense of "removeAll" proposed here.

Agree with Xiaodi on all the previous points. removeAll(equalTo:) is still the best version for me.

> Finally--if it's to be called "removeAll" and we want to use the word "contains" for the equatable version, it would be more consistent to call it "containsAll" and not "containsOnly".

Have to disagree here. containsAll(3) has the same readability problems as removeAll(3).

> On Sun, Apr 9, 2017 at 21:32 Ben Cohen <ben_cohen at apple.com> wrote:
>>>> On Apr 8, 2017, at 5:41 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>>>> 
>>>> On Apr 8, 2017, at 12:44 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> +1. Perfect. Let's not bikeshed this and get it done!
>>> 
>>> 
>>> Sorry, I'm going to have to insist on bikeshedding.
>>> 
>>> `equalTo:` is kind of ugly and has no precedent in the standard library. Similar APIs seem to either leave the parameter unlabeled or use `of:` (as in `index(of:)`). I think unlabeled is probably the right answer here.
>>> 
>> 
>> I think removeAll(of:) works well for the equatable value version.
>> 
>> FWIW of all the ideas from the all thread, containsOnly(_:) for the equatable value version works for me. It has a nice symmetry: contains(3) vs containsOnly(3).
>> 
>>> The main shortcoming I can see is that if you see:
>>> 
>>> 	array.removeAll(3)
>>> 
>> 
>> Personally don’t feel good about an unlabelled version. It doesn’t read right. Remove all three what?
>> 
>>> You might think `3` is either an index or a count. But neither of those actually make sense:
>>> 
>>> * It can't be an index because then `All` would have no meaning. There's only ever one thing at a given index. Besides, indices are almost always marked with `at:` or another parameter label.
>>> * It can't be a count because `All` is already a count. What could "remove all 3" possibly mean if the array doesn't happen to have three elements?
>>> 
>>> And this is only a problem if the value happens to be an integer. If it's anything else, the type makes clear that this can't possibly be an index or count; it must be an element.
>>> 
>>> (But if you really do think this is insurmountable, `removeAll(of: 3)` *is* impossible to misinterpret and fits in better than `removeAll(equalTo:)`.)
>>> 
>>> (P.S. The existing oddness of `removeFirst(_:)` compared to `removeFirst()` and `removeAll()` is why I proposed last year that it be renamed to `removePrefix(_:)`, which matches the count-taking `prefix(_:)` method.)
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170410/d4294ec7/attachment.html>


More information about the swift-evolution mailing list