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 > <[email protected]> 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. > 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. > 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. > 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. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
