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

[Xiaodi Wu]

On Tue, Sep 26, 2017 at 6:48 PM, Robert Bennett <rltbennett at icloud.com>
wrote:

> 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?
>

That's interesting. I worry it might be too clever by half, though.

The prototypical "form" method is "formUnion"; it's so named because the
term "union" is used in math as both noun and verb ("a union b"; "the union
of a and b") and is a term of art that doesn't lend itself to the noun/verb
rule in Swift. Here, "filter" is a term of art (otherwise, it'd be called
"filtered"); now that "filter" is the non-mutating function (i.e., what
should otherwise be a noun), there's no way to maintain the noun/verb rule
in Swift. Therefore, without overthinking it, "formFilter".

Note that it's not "formUnion(with:)", just "formUnion(_:)". As is the case
with "formUnion", no particular attempt is made here to turn this method
name into an English phrase. The phrase "by filtering" very strongly
suggests true-to-remove; that's the only way the term "filtering" is used
in English. Here, we mean true-to-keep, and there's no way to express that
with the English word "filter" between the receiver and the predicate with
any sort of conjugation of the word or concise combination of helper words.
The nearest good-English name might be something like
"formFilteredResultKeeping(where:)", which is clearly awful for other
reasons.

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/ef9b187d/attachment.html>