<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body 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><br>On Sep 26, 2017, at 7:23 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And here are my answers, in a separate email to maintain a shred of separation between objectivity and subjectivity :)<br>
<span class=""><br>
> On Sep 26, 2017, at 4:12 PM, Ben Cohen via swift-evolution <<a href="mailto:swift-evolution@swift.org">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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 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 class=""><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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 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><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>