<div dir="ltr">On Tue, Sep 26, 2017 at 6:48 PM, Robert Bennett <span dir="ltr"><<a href="mailto:rltbennett@icloud.com" target="_blank">rltbennett@icloud.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div></div><div>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?</div></div></blockquote><div><br></div><div>That's interesting. I worry it might be too clever by half, though.</div><div><br></div><div>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".</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div class="gmail-h5"><div>On Sep 26, 2017, at 7:23 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Tue, Sep 26, 2017 at 6:14 PM, Ben Cohen via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">And here are my answers, in a separate email to maintain a shred of separation between objectivity and subjectivity :)<br>
<span><br>
> On Sep 26, 2017, at 4:12 PM, Ben Cohen via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> 1. Is it right to assert that with a “removing” operation, the closure should return `true` for removal?<br>
<br>
</span>Yes. If the closure returned false for removal a different, less readable, name would be needed for the method.<br></blockquote><div><br></div><div>Agree, yes.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>
> 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?<br>
<br>
</span>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.<span><br></span></blockquote><div><br></div><div>Unsure. Maybe and maybe, but I think the confusion/bugs would be limited if the full matrix of four operations exist.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>
> 3. Should we “complete” the matrix of 4 operations, or is it fine for it to have gaps?<br>
<br>
</span>I think filter(_:) and remove(where:) are sufficient. I don’t think we need to complete the set.</blockquote><div><br></div><div>Based on question (2), I would argue that the answer is yes.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>
> 4. If you are for completing, what should X and Y be called?<br>
><br>
<br>
</span>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.<br>
<br>
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.</blockquote><div><br></div><div>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.</div></div></div></div>
</div></blockquote></div></div><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><span class="gmail-"><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a></span><br></span></div></blockquote></div></blockquote></div><br></div></div>