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

[Vladimir.S]

On 01.10.2017 22:44, Thorsten Seitz via swift-evolution wrote:
> `formFilter` strongly implies that the result is a filter, so this would be a very 
> bad choice. i do not follow the argument that it makes sense to just concatenate 
> `form` and the non-mutating method name. The precedence set by `formUnion` is not a 
> good one but at least there it makes sense because using union as a noun preserves 
> the original meaning (the missing `with:` is tolerable) whereas `formFilter` conveys 
> a completely wrong meaning.
> 

FWIW Totally support Thorsten's opinion and replies to Ben's questions.

If we really also need mutating 'filter', why not 'formFiltered()'?
IMO this could be a valid name pattern for Swift in case simple noun like 'Filter' 
has no sense for what the method does: 'form' is a primary marker of mutating method, 
and 'Filtered' just clarifies what we'll have inside the instance in result of that 
call. Very similar to 'formUnion', but with correct meaning.
(Just thoughts... Isn't 'filterInPlace' the best variant ;-) )

I also don't think we need to fill the matrix, 2 filtering methods(one for 
non-mutating and one for mutating) IMO is a good minimum we need, and 'remove' is a 
right in-place filtering method with obvious meaning. If we'll need more filtering 
methods - we can add them later.

Vladimir.

> To answer Ben's questions:
> 
>> 1. Is it right to assert that with a “removing” operation, the closure should return `true` for removal?
> 
> Yes, definitely.
> 
>> 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 do not think that it is very likely and if so I do not think that having to flip 
> the closure will cause confusion because both methods are very differently named.
> 
>> 3. Should we “complete” the matrix of 4 operations, or is it fine for it to have gaps?
> 
> No, it is fine to have gaps. I would consider adding a `removing` variant but as 
> there is no good name for the mutating variant of `filter` I would definitely not add 
> this one.
> 
>> 4. If you are for completing, what should X and Y be called?
> 
> I am against completing.
> 
> -Thorsten
> 
> 
> 
> Am 27.09.2017 um 04:33 schrieb Xiaodi Wu via swift-evolution 
> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
> 
>> On Tue, Sep 26, 2017 at 6:48 PM, Robert Bennett <rltbennett at icloud.com 
>> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <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
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>