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

Robert Bennett rltbennett at icloud.com
Tue Sep 26 18:48:30 CDT 2017


formFilter reads really weirdly... the use of filter in `filter` is not as a noun, but as a verb — compare to e.g., formRemainder. Calling formFilter won’t create a filter, it will “do” a filter. Perhaps formByFiltering?

> On Sep 26, 2017, at 7:23 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Tue, Sep 26, 2017 at 6:14 PM, Ben Cohen via swift-evolution <swift-evolution at swift.org> wrote:
>> 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.
> 
> Agree, yes.
> 
>> > 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.
> 
> Unsure. Maybe and maybe, but I think the confusion/bugs would be limited if the full matrix of four operations exist.
>  
>> > 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.
> 
> Based on question (2), I would argue that the answer is yes.
> 
>> > 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.
> 
> IMO, they should be called removing(where:) [removed(where:) reads weirdly in conjunction with the preceding receiver] and formFilter(_:). Hundreds of messages finally settled on "form" as the in-place verb of choice where the noun can't ordinarily be verbed. No point in being shy about it now: that's the Swift way, wear it proudly.
> _______________________________________________
> 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/20170926/e98b8cd9/attachment.html>


More information about the swift-evolution mailing list