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

Kevin Nattinger swift at nattinger.net
Mon Apr 10 14:30:01 CDT 2017


array.remove(where: { $0 > 3 })
array.remove { $0 > 3 }

> On Apr 10, 2017, at 12:25 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
> On 10 Apr 2017, at 17:17, Maximilian Hünenberger via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> How about this:
>> 
>>     array.removeEvery(3)
>>     array.removeEvery{ $0 > 3 }
>> 
>> I think it preserves the meaning while it reads nicely. However "every" has no precedent in other functions, as far as I know.
> 
> Every has a very ambiguous meaning in English. It could be understood as "every 3 values" as in 0, 3, 6, 9, etc...
> 
>> Am 10.04.2017 um 04:32 schrieb Ben Cohen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>> 
>>> 
>>>> On Apr 8, 2017, at 5:41 PM, Brent Royal-Gordon <brent at architechies.com <mailto:brent at architechies.com>> wrote:
>>>> 
>>>>> On Apr 8, 2017, at 12:44 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/e9e086ad/attachment.html>


More information about the swift-evolution mailing list